One step further

I was wondering why I haven’t had many ideas for a post lately, and it dawned on me that my life is returning to normal. I’m back to eating my daily bread, which, like any loaf, has two crusts. Plenty of developers would like to be architects. Believe me, plenty of architects would like to be developers again, and when they get the chance, even briefly, they’re overjoyed. In a year and a half as an architect I’ve learned to see development in a completely different way from when my decisions affected only a limited set of problems.

Coding, hacking, developing, programming, whatever you call it, is a freer job than you often realize. A mess a developer makes can almost always be refactored or fixed somehow. Architectural decisions reach much further. A developer’s mistake is a Bugzilla defect that lasts a few days. An architect’s mistake can drag on for months or years. A developer looks at the problem through a keyhole, while an architect has to see the whole frame.

I recently reviewed an analysis of a configuration component. It was excellent, by the way. The developer’s job is to design the component. The architect’s is to make sure it fits into the whole product, with an eye to the future.

By the measure of visible work, an architect’s work is hard to see, or at least hard to measure in the short term. That bothered me for a long time. At the end of a day a developer can look back and see something tangible, a working test or a piece of code. It’s like construction, where you can see what the builders have done almost immediately, even if it’s only part of the job.

What’s left after a day as an architect? It took me a long time to realize the answer is decisions. Their effects show up on the scale of weeks and months. An architect has no unit test to validate a decision and no IDE to check its syntax. All you can do is ask someone else to scrutinize the decision and conclusion.