1 May 2002 01:10
RE: Architecture
Charlie Poole <cpoole <at> pooleconsulting.com>
2002-04-30 23:10:43 GMT
2002-04-30 23:10:43 GMT
Laurent, > > Can you explain the further why "making an architectural decision" > > is an admission of incompetence? > > It expands into "I am making a commitment decision *now* about > something on which it would be better to defer the decision, if I > knew how to defer it, or ensure it is disentrenched, if I knew how to > ensure that." I don't see this as being any more or less of a commitment based on whether you call it architecture. All through the development of an application, you make decisions. Some of them you back out. Some of them you modify. Some of them you keep. Of those you back out or modify, some are harder than others. That's life. I think the answer is to make the decisions that need to be made when they need to be made and only then. But once you've made, unmade, remade, backed out and put back in various decisions, there will be a set of architectural decisions expressed in the code. > Case in point, again : I will choose Java because I don't have enough > experience yet in mixing language layers, such that I could switch > between Java and Smalltalk at the drop of a hat. As stated earlier, I prefer not to call anything that names a product or language "architecture" but that's OK, it's still a very important decision usually made early in a project. Often, the factors that lead to that decision are rather trivial: we happen to have a bunch of Java programmers around, so that's what we'll use. Is that a problem?(Continue reading)
You're almost there. On 1: I'm just targeting "decisions", I wouldn't
call "architecture" anything which can be described as a process. On
2: no, not necessarily early. Just those decisions which "cast a
shadow", so to speak, on large portions of the code. Late decisions
could conceivably have this effect. On 3 : no, "blindly" does not
enter into it. Just the notion that they are adhered to because it
would be too costly to just revise them.
> On the other hand, I'm talking about a subset of qualities and attributes
> visible in the code we have written, which in the judgement of the team
> constitute the essence of "how we did this application."
I understand that some people mean that when they say "architecture".
I prefer not to, because a lot of confusion seems to result from it.
For instance, language is definitely a part of "how we did this
application", and is visible in the code. So are various coding
conventions.
On the other hand some "architectural" things under this definition
might not be visible in the code, for instance calling the app "three-
tier" because at the start of the project we had a vision of
separating data storage from business logic, even if afterwards we
did the usual and just sprinkled SQL everywhere.
> If you had five minutes to describe to me how your application works, I
RSS Feed