My Not So Private Tech Life

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

My not so private tech life has been rather quite during the last weeks. That's mainly due to the fact that I'm in the midst of changing my employer, i.e., I'm on holidays with the old one and haven't yet started work for the new one.

Leaving a company and its people behind after seven successful years is quite an emotional experience for me and it made me wonder why I had decided to join andrena objects in 1999. Thinking this over revealed my tiny little "pattern" of how to decide on the right employer: I had chosen the previous jobs because I wanted to find a place where I'd be taught how to do things right. Although I got to know really smart people from whom I learned tons of useful stuff, all in all, no one succeeded in showing me how to do software development - as a profession - right.

With andrena I had changed my tactics: andrena seemed to be a place where I could try out ideas of my own and see if they would work. This was definitely a much better approach which eventually provided me with at least some basic insights into how software development - as a profession - can be done right. Thank you, andrena!

Hopefully, this approach will pay off with 100world as well.

You might think it's over, but it isn't

All garbage has been collected. The remaining trash has been swiped away. But the rats, after having being crammed like kings for two months, miss their additional rations. They somehow manage to enter garbage bins...


...and to get out again through 7mm of massive plastic!

I concede that any analogy can be stretched too far; nevertheless I wonder what's the counterpart of rats in software systems which have seemingly been cleaned up and be ridden of all garbage? Maybe it's us - the consultants - who won't just leave voluntarily when we've fulfilled our task. Not until we are served a poisonous diet.