Why I'm Not An Architect

By Matthew Heusser, May 12, 2005

What is the role of the architect in the software development process? Manager? Coder? Or both?

"I haven't been doing much coding lately" says the former-developer with a wry grin in a strange tone of voice. Or perhaps he says "I haven't had time to code lately." However he says, whatever he says, the implication is clear: This guy has better things to do than to muck about coding.

I heard this yesterday, and something struck me: I've heard this before. Many times, in fact. The wry smile and the tone of voice is not unique. Something was definitely going on.

In this particular case, the former-developer was acting as an architect/project lead. As he saw it, his role was to give input into the business specification, write the technical specification, create a bunch of UML diagrams that defined the system architecture, create the project schedule, brief the developers, and move on to the next project, keeping his hands free of the implementation details [1].

Listening to him describe his role, something really bugged me. He pointed out that he was just separating design from implementation, something done in construction for centuries. In fact, his title was taken directly from construction.

So I asked if he'd ever built a house or worked with an actual architect, and the answer was "no." I mentioned to him that if you want an analogy to borrow, construction is a terribly inefficient choice. I used to work in the McGraw-Hill Construction division, writing software for designers and architects. The finger pointing, needless delays, and confusion between architects and implementers is systemic. In fact, the newest trend in construction is called "Design/Build," where a single construction company is hired to perform both tasks--McGraw-Hill Construction actually launched a magazine a few years back called Design/Build Magazine (http://www.designbuildmag.com/). Design/Builders claim incredible increases in speed, decreases in cost, and improved client satisfaction.

Next I pointed him to the article "Who Needs An Architect?", by Martin Fowler (http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf). In it, Fowler points out that most "architecture" is about having a single, very senior, very smart person who makes key decisions early in the project, because those key decisions are so hard to change and can make life so hard if they are done wrong. Fowler suggests that the whole analogy is wrong, and that if we have an architect, the role should be mentoring programmers to make there own good decisions and decreasing the cost-of-change curve to make changes later in the project less scary, thus not forcing us to get it perfect up front.

Now, don't get me wrong, I'm not saying the architecture idea is bad--hiring a seasoned professional to "mind the store" on a project is a definite improvement for a shop with a few self-trained coders and no unity of vision. My assertion was that the having the architect make technical contributions could make the team better. That there is room for improvement over the "pure architect" analogy.

On the drive home, I thought more about the problem. There was something more to that whole "I won't be writing much code" wink/grin thing that concerned me. Yes, I was concerned that it separates authority from responsibility. If the project turned out bad, or the estimates turned out bad, instead of a feedback loop (to get better estimates next time) it would turn into a finger-pointing game. The architect could always say "Those dumb implementers we hired were too dumb. Next time, we need to hire implementers who are slightly less dumb."

The next morning, I discussed the problem with a co-worker who pointed me to the C2 Wiki article "Architects Don't Code" (http://c2.com/cgi/wiki?ArchitectsDontCode) which claims ArhitectsDontCode is an Anti-Pattern: An idea that seems seductive, but is actually a worst practice or a bad pattern of thinking. The main theme seemed to be that architects who don't code don't have to live with the decisions they've made, so they don't get feedback and a means to improve. Furthermore, architects that aren't contributing technically can lose touch with the problems developers encounter, thus creating designs with painful flaws. As one poster to the wiki wrote: "orchestra directors can (and do) play a lot of the instruments. I agree that the players may be better, but they HAVE to know in order to be able to direct. A person that has a degree in music (like the director) must be able to play chord, wind and percussion instruments (and sing). Let's hope that one day architects on software projects get to the same level."

Looking back on my career, it wasn't just architects that use that expression. People who are looking to move into, or recently moved into, Project Management, People Management, Quality Engineering, Systems Analysis ... the list goes on. In fact, the statement "I won't be doing much coding anymore ..." can be used by almost anyone to assert superiority and boss-man-ship. Often, the assertion "I'm above/beyond/better than that" hides behind the statement. Generally, it is delivered to someone who is coding, so that statement is more subtly "I am above/beyond/better than you."

Now, for purposes of organizational structure, sometimes that has to happen. The supervisor and leader need to be able to lead. Typically, though, the org chart and actual reality match that, so leaders don't feel a need to make sly, slick assertions designed to infer authority. They already are in a position of authority, and secure in that authority, to boot.

The culture problem comes in when every promotion is away from code. The thing is, the work of coding is the work of making the thing that impacts the customer. If everyone is trying to get promoted "away" from coding, then who is actually doing the coding? Anyone? Bueller? The guy who's too dumb to know that he's at the bottom of the caste?

Let me expand on that idea that "the work of coding is the work of making the thing that impacts the customer." UML diagrams don't actually do anything. Neither do specifications, requirements, test cases, methodologies, or procedure documents. In fact, the Agile Manifesto goes so far as to say:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is to say, while we value the items on the right, we value the items on the left more."

-- http://www.agilemanifesto.org

In other words, if you develop a wonderful, complete set of documentation, and your company goes under, the customer is going to do what? Hire someone else who will look at your documentation, claim that it's poor, and start over. The same goes for architecture diagrams, test cases, and methodologies. They don't actually do anything. Only the coder is doing the work of production [2].

I remember a wonderful feeling when I read Ron Jeffries'Extreme Programming: Installed (Addison-Wesley, 2000), in which coding is viewed as central to the role of development: Everything else is support. In that worldview, coding is noble, creative work. Developers can add values through both technical contributions ("hey cool, I found a way to do that in 12 lines of code!") but also through business contributions ("You know, if we knew zip code, we could...") through intense collaboration. In Extreme Programming: Explained (Addison-Wesley, 1999), Kent Beck went so far as to end his preface with something to the effect of "I could write more, but if you'll excuse me, I gotta go code ..." He went on to say that "You can't expect to carry a lot of baggage and move fast. The artifacts we maintain should be Few, Simple, and Valuable ... Like the nomads, the XP team gets used to traveling light. They don't carry much in the way of baggage except what they must have to keep producing value for the customer--tests and code."

An alternative to making every promotion away from code is to create a technical career ladder. Priority Health, Microsoft, Fog Creek Software (http://www.joelonsoftware.com/articles/fog0000000038.html), and Construx (http://www.construx.com/professionaldev/organization/pdl/version1/pyramid.htm) all have technical career ladders. All of them involve incenting developers to get better at coding, resulting in better code developed faster. The alternative involves incenting developers to learn things that have nothing to do with coding, and quite frankly rather scares me.

The problem is that all this so-called architecture really isn't architecture at all. It's some person's vision of world with authority and no responsibility. At Priority Health, our architects are project participants throughout the life of the project. They have "day" jobs where they make actual technical contributions. When they aren't making technical contributions on a project but are assigned to "mind the store", we define the role very similar to the way Martin Fowler does: The Architect is a guide who mentors the developer to make good design decisions, not a boss. As a Technical Project Manager, I feel honored to be invited to code review sessions, to pair on a complex bit of code, or when asked by folks in a crunch to jump in and contribute through code or testing. It's an opportunity for me to keep my technical skills up as well as to actually put real working software in the hands of customers.

Sean McMillan contributed to this article.

Notes

[1] "Programmers shift from design to coding when the problem is decomposed to a level of 'primitives' that the designer has mastered. If the coder is not the same person as the designer, the designer's primitives are unlikely to match the coder's primitives, and trouble will result."
-- Robert Glass, Facts and Fallacies of Software Engineering, "Fact #29" (Addison-Wesley, 2002)

[2] Please don't take that statement too far; testing and requirements gathering are also key. Extreme Programming pushes many of the responsibilities of testing and requirements gathering back onto the software developer. What I am trying to express is that artifacts like activity diagrams do not stand on their own; they only have value along with working software. It is the software that the customer wants, not the UML.

Matthew Heusser is Technical Project Manager at Priority Health, where he manages in-house, integration, and outsourced software projects. He can be contacted at mheusser@charter.net.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!