April 1, 2006

...Learn TDD with Codemanship

Why Did I Quit Architecture?

It wasn't all that long ago when I was something of a dab hand at software design. I'm happy to blow my own trumpet and make the bold claim that I was actually very good at it. It takes more than an appreciation of design principles, or an encyclopedia of architectural buzzwords to be a truly great software architect. You have to have a flair for it. You have to have an intuitive knack for modeling and abstraction. You have to be creative and resourceful.

There's a science to software design, but there's also an art to it. Like other kinds of design, software can have "clean lines" or a playful "flourish" here and there. Of course, the "You Ain't Going To Need It" (YAGNI) school of design is to this style of architecture what the reformation was to catholicism. Gone now are the opulant multi-layered cathedrals we built in the 90's, to be replaced with the spartan test-driven monasteries of the 00's.

And occasionally I hanker for those days. Partly because I got a sense of personal satisfaction from creating ornate and elegant designs that appealed to my own aesthetic, but mostly because whenever I read or listen to architects today, I think "hey, weren't we doing this back in the nineties?"

Architecture - in terms of the body of knowledge - hasn't moved on very much at all. SOA, for example, sounds remarkably like distributed CBD. Design by Contract was important in CBD, and it's just as important in SOA. Of course, DbC is still largely ignored in both!

I know why I don't call myself an "architect" any more. It's become a byword for over-egging the pudding. It's a term that has strong associations with particular groups, like the OMG, of which I am pointedly not a member.

The problem with building cathedrals is two-fold: firstly, once you accept that there is no God, cathedrals serve no purpose. They look fantastic, but to all intents and purposes they're just extremely expensive sheds. The architects of today still have faith that their designs serve a higher purpose. I do not.

Secondly, once you've built your cathedral, you have to persuade people to worship in it. Most software developers are design heathens. Their gods have to serve a practical, workaday purpose, like guaranteeing a bountiful harvest, getting them drunk or getting them laid once in a blue solstice. It might not be theologically sound, but it works for them. The architect's God is just a little too abstract and esoteric for developers' simple stone age minds.

I started to adopt the job title of "software arguer" in my last days as a design authority, because that's what I spent most of my time doing. The problem is simply this: it doesn't actually matter what I think is a good design. Short of writing their code for them, I have to accept that the developers are holding all the cards because they write the code.

The biggest fallacy about architecture is that you can put an architect's hat on and expect people to do as they're told. It just doesn't work. I've never seen it work. The people who've told me they've made it work turned out to be either lying or deluded. Developers don't follow other people's designs. It doesn't matter how good the design is, or how authoritative the designer is. Grady Booch himself could descend from architecture heaven - which is where he spends most of his time these days, I've heard - and pass down the architecture on stone tablets and developers would still say "what the hell does he know?" and carry on doing their own thing.

If you want to know what it's like being an architect, try teaching cats to write peotry. The results are remarkably similar.

Ultimately, who are we kidding? There's at least one potentially important design decision in every single line of code. If I declare a variable, I'm creating a dependency, and - since most architecture is about dependency management - even something inocuous-looking as private DateTime startDate has ramifications on the maintainability, extensibility and reusability of the code.

Indeed, the code itself is a design specification. To write code you have to make design decisions. To be a software developer you therefore need to be a competent software designer. And those are in short supply.

So I had to confront the reality, which is that developers are going to do what developers are going to do, and I should focus on the more useful goal of helping developers to become better designers. Through parlezuml.com, I have reached tens of thousands of developers, and the more conceited part of me - who often gets his own way - likes to think that I've influenced hundreds of software designs for the better, even if by some miniscule degree. If I've helped improve the maintainability of 100 enterprise systems by just 1%, then that stacks up to potentially millions in savings over the lifetimes of those applications.

It's a point of view that paints me into an interesting corner. I feel it's very necessary to teach "the old ways" and that every developer should be capable of knocking up a decent Parish Church at the very least. But I'm very much in the YAGNI camp myself these days, and I believe very firmly that designs evolve - whether you like it or not. The new design style I've been seeking has an emergent aesthetic. These designs grow like stalagmites and stalactites. The new cathedrals are more like caves, though they can be equally breathtaking if you do it right.

My "design muscles" are stronger than ever. I have wondered about how this could be so, since I haven't been an architect for quite some time. Interestingly, a jazz musician's "composing muscles" tend to be stronger than a classical musician's. I think the reasons might be the same.

A jazz musician has to be able to read complex music and execute it faithfully. In that respect, they're little different to classical musicians. But a jazz musician must also be able to improvise - to make up music on the spot. This improvised music has to fit in with the other instruments, and it has to respond to what's going on around it. In turn, other instruments respond to the jazz musician's improvisations, and the music co-evolves as they play off each other.

I know from experience that this takes much more skill and creativity than playing music straight from a score. The results can be a little hit and miss, but more experienced jazz improvisers tend to hit much more often than they miss. In Jazz, just like any other style, there are rules and principles, and these need to be internalised through years of practice. And it helps if you have a flair for it...

As an architect, I practiced design like a classical composer sitting alone at his piano slaving over every note. The results were interesting, symphonic and - arguably - difficult to play. Like many composers, I wrote for my own aestheic and my own abilities. The term "self-indulgent" springs to mind.

As an Agile Developer, I've been making design decisions on the fly, in direct response to what's going on around me. This has really helped hone my instincts for good design. Jazz musicians need a good ear. They need to be able to instantly recognise a Cm7 chord and know what scales and modes they can play over that. They don't have to time to look it up in a book. Their fingers have to "know" it before they do - if you'll pardon the clumsy expression.

I have felt my own sense of design improve, and I'm sure if I were to objectively measure the design quality of my code based on these instinctive decisions, it would be a significant improvement on what I could do if I deliberated more.

So you'll have to forgive me if, when I look at today's "new architecture", it all seems a bit old-fashioned, self-indulgent and over the top.

The architect in me didn't die out. It just evolved into something better.
Posted 14 years, 9 months ago on April 1, 2006