Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Should Software Architects Write Code?

Much has been written and debated on whether software architects should write code. Many argue the more architects understand the language, tools and environment they are designing for, the more effective they are and this is best achieved by implementing some or all of the design. Non-coding architects, sometimes called “PowerPoint architects”, “astronaut architects” or “ivory tower architects”, may use archibabble and talkitecture to convince non-technical stakeholders of their expertise while delegating the unsolved, real problems to developers, so much so that it has become an organizational pattern (“Architect Also Implements“) and corresponding anti-pattern (“Architects Don’t Code“). Others argue that architects responsible for implementing their architectures lose focus on the bigger issues and longer term vision. Understanding does not necessarily require knowledge of the minutiae and, as systems scale up and diversify, implementing it requires too much time or spreads the architect too thin. Therefore, should software architects write code?

As with many difficult questions, the problem starts with the question itself. “Should a software architect write code?” can mean “Should a software architect always prototype or implement their own architectures?”, “Should a software architect write production code most of the time?” or “Should a software architect be able to write code?”. It could also mean “Is coding the best or only way to become a software architect?” or “Can non-coders be good architects?” but that is best left to another blog post.

It also depends on the definition of “software architect”. The Canadian architect (of buildings rather than IT) Witold Rybczynski wrote in his 1989 book “The Most Beautiful House in the World“:

“For centuries, the difference between master masons, journeymen builders, joiners, dilettantes, gifted amateurs, and architects has been ill defined. The great Renaissance buildings, for example, were designed by a variety of non-architects. Brunelleschi was trained as a goldsmith; Michelango as a sculptor, Leonardo da Vinci as a painter, and Alberti as a lawyer; only Bramante, who was also a painter, had formally studied building. These men are termed architects because, among other things, they created architecture — a tautology that explains nothing.”

This is exactly the same issue for software architects. Without a clearly defined and segregated role, anyone designing software or IT related systems can rightly be called an architect, including many developers and technical leads. For the sake of argument, this post uses Simon Brown’s definition, where software architects are responsible for high level design, non-functional requirements and technical vision.

Should a software architect be able to write code? Architects should be able to read and write code because it:

  1. Verifies the code written by developers matches the design and identifies deviations.
  2. Helps the architect learn about changes or new features. If the architect has been assigned to a new project, he or she can learn the product sooner by looking at the code, too.
  3. Allows the architect to write a proof of concepts or prototype. A working demo is much more convincing than an architecture diagram and will usually facilitate better estimates. Care must be taken to prevent non-technical stakeholders attaching too much credibility to it, as with any prototype however.
  4. Provides another pair of capable hands during the project crunch periods.
  5. Makes the architect more forgiving of bugs because the architect has likely made similar mistakes in the past. At least, the architect should have a better understanding what types of issues to expect.

Writing code may help earn the architect respect of the developers. Developers can be notoriously dismissive and a software architect producing some of his or her own code, even if it is just a proof of concept, or providing good feedback from a code review can make the developers feel like the architect is one of them. Having a working development environment and access to source code means the architect can try out new versions without waiting for a build or release. Any significant build, development environment or source code control issues also become apparent to the architect.

Note that code reviews do not replace talking to developers because regular discussions between developers and software architects can help build mutual respect. Otherwise, developers may see the architect as a constraint or threat that must be circumvented. Also, developers often know or can find problem areas faster than the architect reading the code but there needs to be a balance between architect self-sufficiency and squandering developer time.

Software architects are often required to settle disputes between developers, such as when one team discovers a better way of solving a problem or that the proposed design will be harder to implement than first thought. Software architects are also sometimes mentors or coaches for developers or may be used as internal consultants to examine process, quality, automation or similar issues. Understanding code means the architect can use his or her judgment more effectively rather than rely on which developer is more persuasive.

Should a software architect write production code most of the time (usually implementing their own architecture)? If a software architect implements their own architectures, this ensures the design is implementable with the tools and environment used. This can lead to new insights, improved designs and more accurate estimations. It is also implemented by the person most familiar with the design so minimizes miscommunication.

However, architects may jump to implementation (depth thinking) before exhausting other solutions (breadth thinking). Existing implementations may overly influence the architect or the architect become attached to his or her code, fighting against needed improvements. It can distract the architect from higher level tasks such as longer term planning, communicating with stakeholders and reviewing other developers’ code.

Also, part of the role of an architect is to fight for reuse, security and other non-functional requirements. Being forced to prototype or implement their design may encourage compromises that the team need not make. It is not that an architect does not make compromises – design is the art of compromise as many have said – more that it is the architect’s job to make the right compromises rather than those the architect makes creating the initial implementation. The developers will likely rewrite much of the architect’s code, anyway.

Indeed, the more an architect focuses on communication, requirements analysis, stakeholder management and non-technical activities, the more the development skills of software architects may atrophy. As long as the architect is providing value via other means this is not an issue. However, an architect should maintain his or her development skills; whether by extensive research, working on their own projects or contributing where they can; but needs to focus on capabilities, limitations and edge cases rather than speed or a complete understanding.

Problems may occur when organizations promote their strongest developers into a software architect role rather than good communicators that are capable of working at higher levels of abstraction. Friction arises when these architects try to “lead from the front” by implementing their architecture rather than facilitating others to do so. Organizations should promote a developer that has better soft skills, instead.

Many confuse not writing code with a lack of feedback. An unprototyped architecture, hypothetically, may be difficult to implement or problematic. However, a senior developer or technical lead can prototype the architecture if required. This also allows architects and developers to work together and ensure the design is communicated well. Alternatively, the architecture can be shared with others that have implemented similar systems previously or architects or developers working on integrating products. Requiring an architect to implement their own architecture beyond a proof of concept also does not scale well, particularly for large or complex products.

Similarly, many confuse an architect not writing code with a lack of accountability. Architects must produce designs that not only are approved (whether formally or informally) by stakeholders but also developers and developers should not approve a document that does not meet their needs. Issues or errors in the designs should be noted. Some change is expected but major or expensive errors should be attributed to the architect. An architect implementing their architecture in code does not guarantee an issue-free project.

With increased use of agile development methodologies, architects are no longer creating an architecture and “throwing it over the wall” to developers. Even previously ivory tower architects are more involved with lower level issues since less critical decisions are deferred until later in the process and design is iterative. For example, architects in organizations using Scrum should attend at least the planning, review and retrospective meetings. (Some architects may move to other projects or otherwise not see the project through, the “Architects Play Golf” pattern. This is an organizational issue and unrelated to whether architects code.)

Many developers also look down on “PowerPoint architectures”. However, many forget the role of a software architect is as much communication as development and completed, implemented architecture does not help non-technical stakeholders, QA, localization, documentation writers and so on. Of course, these stratospheric PowerPoint architectures are not substitutes for high-level designs developers can implement but the architect represents the developers and products to outsiders and developers often feel any time not spent developing is unproductive. Ultimately, PowerPoint architectures do have their place but developers are as much the architects’ customers as the stakeholders.

Should architects write code? The question is loaded and should be determined by the team on a case by case basis. Architects may prototype high risk projects, experiment with new libraries or try out now tools. Architects may completely delegate the design and implementation of well understood, low risk components. The real question is “How does an architect be successful?”. It is a question of managing and mitigating risk. Architects are often good coders but good coders are not necessarily good architects.

Update: There is a large discussion about this post on the IASA (International Association of Software Architects) LinkedIn group: http://www.linkedin.com/groups/Should-Software-Architects-Code-1523.S.188454845

12 responses to “Should Software Architects Write Code?

  1. Van February 22, 2013 at 11:24 pm

    With language features supporting inversion of control, and separation of concern, there is nothing that stop an architect to code a framework which is then passed down to detail design andimplementation by developers. JEE is one good example.

    • Anthony Langsworth February 22, 2013 at 11:38 pm

      What you say is true (and I assume you meant J2EE in the last sentence). I think it comes down to the relationship between the architect(s) and developer(s). If the design is captured well enough for the developers to jump in, the architect may leave it to the developers. However, often the architect wants confidence in the design and so may prototype or write the framework first (or the architect just wants to maintain his or her development skills).

      • dagregster April 17, 2013 at 5:46 pm

        I absolutely agree Anthony. The best designs I’ve done have been because I’ve been able to put some code together to show developers HOW it works. I see code as a design tool as well as a production tool and I aim to show as much of the design as I need to so that the developers can see what the design DOES. I simply can’t understand why some people think that architects should stay away from code. I’ve even had this from developers in some cases but I think this is more of a role-conflict problem than anything else. Ironically, these developers are more than happy to forge the architecture through their code!

      • Anthony Langsworth April 17, 2013 at 8:40 pm

        You sum it up well when you say “code [is] a design tool”. Whether architects should code is not a binary (yes/no) question. It is how the architect uses code to validate and communicate the design.

  2. Pingback: 软件架构师是什么?他们应该写代码吗?

  3. Pingback: 软件架构师是什么?他们应该写代码吗? - 科技辣

  4. Ashraful Alam (@AshrafulAlam) July 10, 2014 at 7:23 pm

    In simple and short: Software Architects can be categories in two levels: Design Architect & Implementation Architect.
    Design Architect’s responsibilities include
    (1) Providing technical structure that meets customer and business goal, budget accordingly
    (2) Providing a set of standards (best practices, conventions, cheat sheet etc) to be followed by its implementers.
    An implementation architect bridges between the top level design and implementation, where he focuses taking the right decisions from deeper technical perspective (i.e. implementation of a certain algorithm with appropriate libraries etc).
    For small and medium projects a single person may play the both role, whereas for complex projects or products, multiple persons may get involved.
    No matter a person is Design or Implementation Architect; he is required to come from a strong implementation background and should have a significant involvement in coding (from 30% to 70% of his time depending on project or product size and available resources).

  5. Pingback: Should a Software Architect Code? is the Wrong Question | Chris F Carroll

  6. Pingback: Should a Software Architect Code? is the Wrong Question – Chris F Carroll

  7. Pascal Enz May 18, 2019 at 12:37 pm

    Great post Anthony!
    You mentioned the most important aspect in the last paragraph: Risk mitigation – one of the top reasons why we do architecture in the first place. An unverified design that only exists in Visio or PowerPoint is a risk in itself. I have seen way too many times that designs – including my own ones – fall apart during implementation because too many significant details got lost in abstract high-level thinking. In fact, I held a training session with my current development team a few weeks ago and my advice was, if an architect gives you a design that has not been verified by some form of POC, reject it!
    Secondly, I also believe software architects needs to be great outside-the-box thinkers to come up with good solutions and to constantly improve existing designs as the software evolves. However, creativity only happens after we spend a lot of time thinking about and incubating a topic. From my personal experience, just working on abstract diagrams and reviewing code or other artefacts is not enough to truly stimulate creative thinking. Some form of experimentation is required and for a software architect, that most likely includes coding.

    • Anthony Langsworth May 18, 2019 at 6:32 pm

      Thanks, Pascal. Great points that I am also rediscovering as I move away from software architecture to solution and enterprise architecture. Discussions with subject matter experts, industry standards and academic research are also useful verification mechanisms and help breadth-first thinking, too. These also make your designs more persuasive and compelling.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: