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.
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.
|Software architects also develop||
|Software architects don’t develop||
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.
- In the mid-1990s James Coplien captured the organizational pattern Architect Also Implements.
- The Architects Don’t Code anti-pattern on Ward Cunningham’s C2 wiki is also a valuable read.