Should Software Architects Write Code?

Source code
One of the age-old debates in the software world is whether software architects need to write code.  We suspect that as an industry we’ll never reach consensus on this topic. Here are our thoughts on the subject.

Short Answer:

Hell yes!

Detailed Answer:

In the following table we list the advantages, disadvantages, and considerations (when does the strategy makes sense) to compare whether a software architect should write code or not.  You may recognize this approach from our book Disciplined Agile Delivery.

Strategy Advantages Disadvantages Considerations
Software architects also develop
  • Helps to keep the architects grounded
  • Developers are more likely to respect the architects and follow their advice
  • Architects are able to create working examples of their strategies, increasing the usefulness to developers
  • More people with architecture skills are needed to support your development teams (arguably a good thing)
  • Apply when you have an ample supply of people with architecture skills, or at least are willing to invest in developing sufficient people
  • Apply when it is critical that developers build well-architected solutions
Software architects don’t develop
  • Architects can focus on architecture
  • Architects can support multiple delivery teams
  • Developers are far less likely to follow the advice of such architects, effectively forgoing any benefit the architects could have brought to your organization
  • The architects are forced to create less-effective artifacts such as white papers and models, as compared with working reference architectures, due to lack of coding skills
  • When you have very few people in your organization with architecture skills
  • The software architects should pair with others so as to transfer their architecture skills to them, thereby growing the pool of software architects and thus making it more viable to allow the software architects to code

In the Disciplined Agile framework we’ve made it very clear that we expect Architecture Owners to be actively involved with the development of the solution.  On Disciplined Agile teams the Architecture Owner is effectively a team member with additional responsibilities around leading the team through architecture decisions, in coaching them on architecture skills, and in working closely with your Enterprise Architecture team (if any) to ensure their development team understands and is working towards your organization’s technical roadmap.

We’re often told that it isn’t realistic to expect architects to write code.  Invariably this is coming from people who are currently working in traditional IT organizations that have very well-defined roles, IT organizations that more often than not are struggling to be effective.  Our response is always the same – Really?  Are development teams following your architectural strategy?  Are they eager to work with you, or are they forced to work with you?  This generally leads to a discussion that reveals that things aren’t going so well for these architects in practice, and sometimes leads to a positive discussion as to how we can move towards a more effective approach for them.  They kind of approach described in the Disciplined Agile framework.


Additional Reading:


9 thoughts on “Should Software Architects Write Code?

  1. Gary K Evans

    Good blog, Scott. I will spell something that is implicit in your article. Any architect who does not prove his or her architecture with actual working code (an application or POC that incorporates the components, APIs, and protocols) has nothing but paper, “lines and boxes” to sell to the organization and no basis to be trusted by the dev teams. An architect who does not still write code is like a man with opinions: you get what you pay for.


    I have found a factor that can be (but isn’t necessarily) a huge disadvantage of having architects also develop: the willingness to follow development procedures. Some architects are unwilling or unable to follow normal development practices. Those practices were established for good reasons, such as maintaining code quality, maintainability, management planning, and other factors. When an architect does not keep project status tools updated, or use them at all in some cases, then management cannot predict whether the project will complete on time, which means that they cannot take preventive action if the project is in trouble, until far too late. I know that the solution is to force architects to follow development procedures (or fire them), but this is not always practical from a political perspective.

    1. Scott Ambler Post author

      Interesting point. I prefer to see this as a learning opportunity for the architect to come up to speed on the current development procedures. When the architect is embedded in the team, as is the strategy promoted for the Architecture Owner role in Disciplined Agile, then this usually isn’t a problem. When they drop in and work with the team on a part time basis I can see this being an issue.

    2. Valentin Tudor Mocanu

      The enumerated development practices are part of the architectural style , that is a imports part of the job & responsibility of an architect. If not, then maybe is not an Architecture Owner, but rather an Architecture Researcher. We must make the distinction between development for production and development for research.

  3. Tom Grant

    Scott, great post on a vexing question. While there should be more architects on teams, instead of floating in (from the team’s perspective) the nethersphere outside them, there are risks. One anti-pattern I’ve seen is a larger version of what Mr. Nobody cited, a poor interpersonal mesh with the team. There are a lot of destructive behaviors I’ve seen on the part of architects on teams, beyond just not following the same code review or testing approach that the other team members follow. Sometimes the problem is arrogance, sometimes it’s something else.

    There are also architects who, under pressure, devolve into senior developers. They just don’t, or can’t, devote the time to being a good architect. Again, many reasons for this anti-pattern exist.

    I wrote a longer version of these thoughts over at the Cutter blog. This post got me thinking about the topic, since it’s one that I agree should get more attention. Thanks again for the thought-provoking piece.

  4. Larry Brunelle

    The best architects I’ve been acquainted with develop, and remain facile at development.

    There’s a really old story for which I wish I had the attribution. There was a chap who used to visit a hunting lodge every season, and he always worked with their best dog, who was named Salesman. With Salesman, he’d always come away with the limit in whatever game he was hunting. So one year her returned and, as usual, asked for Salesman. He was told, “Can’t have him. He’s no good any more.” “What! Why?” the customer responded. “Well,” he was told, “a while back a group of executives came through here, took him hunting, and started calling him Sales Manager. Now he just sits or his tail and barks.”

    The parallel is, I hope, obvious.

    I’ll babble just a bit more. I think that every good developer wants so much context as can be had, for understanding if for no other reason. The ideal situation is every architect a developer and every developer an architect – everyone on a team knowing both how to produce beautiful code and how to contribute to an elegant architecture. And everyone becoming progressively more expert on THIS architecture.

  5. Michal Davidek

    “Hell yes” is the right answer even for me. As for Larry Brunelle, the best of architects were also developing a code. Also they were at first line when something with their proposals were wrong and were able to admit a mistake.


Leave a Reply

Your email address will not be published. Required fields are marked *