My Not So Private Tech Life

My personal opinion on this is "only barely - if at all". If you can read German then Jens Coldewey's very good summary of the problems you run into if you try is just for you. Here is my adhoc translation of a section in which he characterizes his experience with refactoring large C++ legacy systems:

To rework and refactor a whole system like this can take years. Languages that enforce such big rework should not be used anymore except in very special circumstances. Would you buy a new car the engine of which was developed in 1980 and which contains many concepts of his 1960 precessor?

In case you have known me or this web log for a while you probably know that I am all into the evolutionary style of software development. In other words, I am a strong believer in the theory that software design - and software architecture as well - should be tackled step by step, from very easy to (maybe) a little bit more complex, from one requirement to the next. My experience so far has been that almost anything which had to be designed or "architected" could be - or could have been - done in the evolutionary style; see my talk on Evolutionary Software Architecture for more details on that subject.

I emphasized the "almost" in the section above not to stress the impossibility of evolving certain architectural characteristics - I just haven't seen it being accomplished so far - but to point you to an analogous theme: Biological Evolution vs. Creationism. It's the likeness of rationale that strikes me: Creationists very often take an isolated biological item - say the third vertebra of a frog's cervical spine - and argue that since no biologist has shown how this bone could have developed in many iterative steps it must have been created by God. As soon as this issue has been tackled by a PhD thesis or five the next detail will be used to "prove" that "intelligent design" must be at work (see Richard Dawkin's book The God Delusion for more about this topic). I've had to face many similar arguments from proponents of up-front-design and -architecture: "How can security, internationalization, persistence etc. be built into a system step by step and in retrospective? You have to do it right from the start!" I often don't have an answer then ... until someone describes how she did exactly that. I've seen that happen with internationalization, transactions and lots of other stuff and I'm sure more seemingly uncrackable nuts will follow.

Analogies of this kind are a slippery slope, and I don't want to imply that proponents of up-front-architecture have as weak a case as creationists do. No, I'm fully aware that there are systems that have been developed that way and that are as healthy as their evolutionary counterparts. The thing I want to stress, though, is that a few unsolved sample problems are not enough to weaken a theory that comes with strong supporting facts.

Evolutionary software architecture (ESA) has been one of my favourite topics for quite a while, despite the fact that I often look down my nose at people calling themselves "software architects". If you're interested in ESA (and if you understand spoken German) you can listen to my take on it or just read the slides.

Now - for our customer's sake - I'm sometimes called an architect myself; that's why Willem's article on customer-oriented architecture made me reconsider my attitude about "software architects" in general and my personal approach in particular. He writes:

I used to like the “architect also implements” pattern. Johanna Rothman’s "Architects Must Write Code" seems to be a more prescriptive variant of the pattern - I’m missing the contexts in which it applies, and contexts in which it doesn’t. Reading "Architect as Consultant"? it seems Johanna believes architects who don’t program on “the project” can’t work. [...]
If you’re building just a house, “architect also implements” might be feasible, or maybe it is the master builder that also designs. If you’re re-building a city, having the urban planner run around with a hammer and a box of nails would be seen as micro-management.

I whole-heartedly agree with Willem's point of view that a software architect's role strongly depends on a project's context - size being one of the more important contextual parameters. As for me it all comes down to a few principles:

• A good architect has to be very knowledgeable on the topics he considers to be his realm of decisions & recommendations. He must be able to actually show how his recommendations can be realized at the next lower level.
• An architect should strive for getting as much concrete feedback as possible and as quickly as possible in order to (dis)prove and adjust all decisions he's been making.
• An architect must stay long enough to face the music of his decisions. In other words: He's the last to leave the sinking software.

In projects where "the architect" has the last word as for programming model, design and development approaches those principles basically lead to our starting assumption "Architects Must Write Code", at least now and then. The larger the project and the larger the organization the more there's a need for someone considering full-time how the suggested software can be divided (and conquered), how the system will be embedded in the existing landscape and how all this fits in with the company's "strategic" development platforms and ERP systems. In those projects, however, there's probably room for a couple of architects, all of them with different decision scopes. And probably we should give them different job titles, too.

That said, I still have difficulties to imagine a software architect of value who cannot write code (any more). In the end, even Frank Lloyd Wright was able to hammer in a nail straight and sound and in the exact right spot. At least, I wish he was that sort of guy.

Update

Willem followed up on this story with Architect also hammers nails. However, there seems to be a flip side to Frank Lloyd Wright's way to trade-off form against function. In Stewart Brand's How Buildings Learn Wright is cited as follows:

If the roof doesn't leak the architect has not been creative enough.

I wonder whether that fits my idea of quality software. I bear with him, though; we all have our skeletons in the closet.

Johannes