The myth of the non-coding architect

I've been missing coding a little lately, and I've been wondering whether a non-coding architect really is worse than no architect at all. The biggest risk I see is that they lose their feel for the finer details. Above all, an architect needs context, but keeping the context of a larger system means stepping back from the problem a bit. The two forces pull in opposite directions. Stepping back is generally easier than keeping your feel for the details, because you develop that feel best by writing code yourself.

As an aside, my hair sometimes stood on end in interviews when candidates for architect roles said their idea of programming was putting together a proof of concept or, heaven forbid, trying out frameworks. In my humble opinion, that's the quickest way to make development teams hate you.

When I talk about programming, I mean really getting your hands dirty. That's quite different from getting HelloWorld to run somewhere and declaring you've found the right technology. Unfortunately, it takes more than a few hours a week. I think the warning about non-coding architects came about because the architect's job had slipped into choosing technologies and running HelloWorld experiments above all else.

At GoodData we have two roles formally called architect. One is closer to a coding architect. That person works much more closely with the Scrum teams and is usually responsible for no more than a few services. They get their hands dirty with code quite often, and for them, giving up coding would be fatal. They're involved in day-to-day technical decisions down to the smallest detail. The other role we call architect assumes you have a picture of how the entire system works.

In my job, for example, when we build a data center in Europe, I understand the architectural impact across different parts of the system, from data security to deployment. You need that feel in this role too. It's easy to say “replicate the data between data centers” at your desk with a doughnut in hand, but the implications for implementation are far-reaching. It seems to me that you develop that feel through experience, without needing to code for hours every day.

In this role I miss coding because it was fun, but I don't think it's necessary, at least for now. Most of the time you're more of a negotiator, trying to feed the wolf and keep the goat whole, so to speak. Instead of deciding whether to use framework X or Y or whether to indent with tabs or spaces, you design and extend the system with all the stakeholders in mind: developers, customers, product management, support, finance and so on. So instead of reading books like Seven Languages in Seven Weeks, I'd suggest taking a course in behavioral psychology, negotiation and compromise. That's what the job is primarily about.