Architects Should Code: The Architect's Misconception

Posted by Brandon Bryson on Aug 06, 2015 |


When I interview people for architect positions I usually ask a question like: “Do you think an architect should do any coding?” And I usually get one of two responses:

“No, I look forward to advancing to a position where I no longer work with code.”

“I’d love to continue coding, at least some amount, but I probably won’t have time.”

Similarly, when I ask other architects how much they’ve coded recently, more often than not I hear:

“It’s been a while.”

These responses are always disturbing. Since when did advancing in a technical role come to mean separating from technology and delivery?

How does one expect to navigate the vast landscape of technology options and understand how they play within their enterprise without staying plugged in to the teams that implement those technologies? Or, better yet, implementing them oneself?



Collecting feedback and providing leadership are two key benefits of staying engaged with the delivery. 


An engaged architect will be present to witness feedback first-hand and available to work with the team to mitigate any deficiencies. Feedback can come from a number of sources such as changes in enterprise standards, changing or evolving functional/non-functional requirements, and challenges discovered during implementation and testing.

The earlier these deficiencies are identified the faster the architect can evolve the architecture. If the architect is not actively engaged with the delivery team then this feedback could take weeks or months to bubble up, usually very late in the delivery cycle.

Given that the architectural decisions usually encompass those things that are most important or hard to change, this lag in feedback will only compound if significant architectural changes are required.

Discovering architectural deficiencies late in the cycle usually leads to workarounds and technical debt to “just get through this release.” However, the earlier this feedback can be captured and assessed for architectural impact, the more agile the entire project will be, and less risk will be accumulated.


Another primary responsibility of any architect is to provide leadership. Leadership can take many forms, all of which are important to the successful implementation of any effort and its underlying architecture.

Architectural leadership requires the architect to effectively communicate the "big picture" to the team for successful realization. The best way to relay this information is by working closely with the delivery team and having several contextual discussions, not through one document or one meeting or one speech. The architectural direction must be reiterated throughout the effort. It is all too easy to get caught up in the heat of delivery and lose sight of the overall goal. Having an architect that is continuously engaged will help maintain a consistent vision.

Technical leadership stems from the fact that the architect is often highly experienced in development and delivery. A goal of the architect should be to educate and grow the development team. Sometimes there are specific tech leads that play this role, but why horde the experience gained by the architect? Not only does this interaction benefit the team as a whole, it benefits the architect to understand some of the common issues the development team encounters.

Mentoring is a form of non-technical leadership that an architect can impart on a team. Topics like working with non-technical people, embracing Agile principles, defining architecture, and modeling architecture are all important skills for growing developers and future architects. Much of the training and knowledge of an architect's role is gained by way of on-the-job experience as opposed to more formal, classroom-type educational opportunities. An architect should embrace this tendency and make architectural learning active rather than passive.

Tactics for Enhanced Engagement

An engaged architect may not necessarily be picking stories for individual delivery. Actually, depending on several factors like architect-to-developer ratio or number of external project commitments, having the architect solely own and delivery stories may be a less optimal approach. Following are some tactics for aligning the architect with the delivery and improving the interaction between the architect and the team.


Martin Fowler mentioned in a 2015 O’Reilly Software Architecture conference keynote that pairing may be a good option to keep the architect involved. Pairing, or Pair Programming, is an agile software development technique, made popular with the Extreme Programming methodology, in which two team members work together at one workstation to accomplish a common goal. In this scenario, the architect never actually owns a story independently, but pairs with others on the team to perform any required design, development, and/or testing. This approach has the advantage of keeping the architect committed to the delivery and close to any architectural feedback discovered, while shielding the team to resource churn in those instances where the architect must tend to extraneous responsibilities.

Peer Reviews

This approach is similar to Pairing, though with a slower feedback loop. Peer reviewing is when a peer reviews the work of another, usually after most of the work is completed, for quality. Here, the architect works with the developer to peer review the code, either periodically or once toward the end of story completion. Through this approach the architect gains insight into architectural adherence or issues preventing adherence and has the opportunity to provide leadership in the form of development advice.


The architect could lead a development spike focused on architectural discovery or delivery. A spike is a functional, proof of concept implementation for some aspect of the architecture used to identify or mitigate risk by exploring a new technology. Spikes provide an excellent opportunity to see the architectural decisions realized, contribute directly to the delivery goal, and promote more immediate visibility into deficiencies or limitations of the architecture. They also encourage that the architect be directly involved with implementation, collaborate with the team, share the architectural vision, and immediately benefit from any lessons learned.

Story Development

The architect could be a team member and perform actual story delivery. This is probably the tightest feedback loop possible. The disadvantage to this approach is the risk of the architect becoming too narrowly focused on individual stories (missing the forest for the trees). Maintaining the architectural vision and forethought must be balanced with detailed design and hands-on implementation. As an additional caution, this approach could play havoc with tracking a consistent team velocity. For example, if the architect is working stories for three weeks then pulls out for two weeks to perform some high level tasks (i.e. road mapping), this could create some churn in the team’s overall velocity. First, though I agree that short term velocity may be impacted; long term velocity should be impacted significantly less as the law of averages takes over. Second, if the architect is working on high level, project-related work, then those tasks should be stories alongside the delivery stories, reducing the amount of “shift” that an architect must manage bouncing between high and low level tasks.


In this tactic, the role of the architect is transitioned amongst team members for some set duration. During each person’s time as the architect, they carry the responsibilities of making architectural decisions, maintaining architectural cohesiveness, and providing overall architectural guidance. Rotating the architect role among different team members carries the benefit of increasing the overall team’s working architectural knowledge. Team members gain a better understanding of all the roles involved in delivery, leading to empathy between team roles, improved intra-team interaction, and a better overall product by diversifying the viewpoints applied to each role. I'd recommend rotating sparingly as the inconsistency could actually cause more disturbance than benefit. Somewhere along the lines of major releases (3-6 months) may be appropriate, depending on your team make up and release cycle duration.

Engagement Approaches to Avoid

While there are several tactics to improve an architect’s engagement with the delivery, there are also approaches that an architect could take to be involved but may be overall detrimental to the health of the team and the effort and should be avoided.

Only the Difficult Stuff

One tendency might be for the architect to take on all the difficult work, whether that work is captured in stories or otherwise. This could seem intuitive given the usual seniority and experience of the architect; however, in the long term this is detrimental to the team. First, by not being involved the team might not fully understand, nor be able to support, these complex nuances of the system. Second, software developers enjoy challenging work. By working all the difficult problems, the architect deprives others of digging in and learning something new.

Take Over

Another discouraged approach would be to just take over the delivery, command-and-control style. Given the time and effort the architect has spent on defining the architecture, there is significant incentive for a successful delivery, especially if the architect will be part of the delivery team. The architect may have the tendency to overly control all aspects of the delivery, rather than help guide the delivery toward the architectural goal. This approach could have the following detrimental effects:

  • Create a team that resents the controlling architect rather than one that is self-organized, highly functional and collaborative.
  • Limit the ownership and growth opportunities among team members.
  • Fail to scale to larger deliveries.

Driving the Details, Not the Essence

When pairing or performing code reviews the architect should be driving the essence of the need, not the details. There are many ways to code even the simplest logic, and many of them are perfectly functional, even though they may not mirror how the architect might do it. The architect must guide toward the architectural direction and enforce local coding standards, but also allow for some poetic license.


To realize a successful architecture the architect must stay engaged with the delivery team throughout the lifecycle. Staying engaged promotes a quick feedback loop into the architecture. It also provides more opportunities for the architect to communicate the architectural vision and provide technical leadership to the team. Although the architect could code, as the title suggests, there are other ways for the architect to stay engaged with the delivery, such as pairing and peer reviews. Conversely, there are ways to stay engaged that could be detrimental to the team, such as taking over the delivery and now allowing the team to self-organize or otherwise take collective ownership. A key goal is to avoid the "ivory tower" architect persona that decrees the architecture up front then is never seen or heard from again. Strive for a collaborative relationship with the delivery team, working together to identify and remedy architectural deficiencies as early as possible to deliver a success architecture and final product.

About the Author

Brandon Bryson is a Senior Consultant at MasterCard, a technology company and payments industry leader, focusing on application architecture, development, and agile delivery.  He is a 15 year veteran of the software industry with a passion for technical leadership, architecture and design, agile principles and the confluence of the three.  He has worked at Fortune 500 and start-up companies across a number of sectors including defense, travel, supply chain, and financial and has a degree in Computer Science from Mizzou.

Rate this Article


Hello stranger!


Get the most out of the InfoQ experience.

Tell us what you think


Email me replies to any of my messages in this thread

If you are not coding ... by Mark N

... you are not and cannot be an architect. Period.

Becoming an architect is not the next step after lead. Your best developers might not have the abilities required for architect.

Almost fully agree by Hermann Schmidt

As architect with only juniors around me, I better do the difficult stuff myself, at least those parts, which are vital for a system and affect lots of other parts. The team can watch, learn, and after that, take over. Don't overload inexperienced developers. It's neither good for them, nor for the project.

Or, as a wise architect should always answer: "It depends". In a team with veterans, an architect has a lot less trouble, or maybe isn't needed as such. He or she may get the task to explain the work to management or get more involved in the requirements process.

My observation in the industry is that I can tell when non-coding architects have left development. That's where they had stopped learning. They promote concepts from that particular era as if they were convinced that they had learned all which is to learn back then. Big mistake.

Magical architecture by Jeff Hain

It's hard to put the leash of reality and feedback on a dog
once you've put the crown of abstraction and irresponsibleness on its head.
(~ Tyrion).

An architect should be passionate about producing UML diagrams
as a writer should be passionate about producing tables of contents.

Every time I spoke with an architect who thinks his job is UML and
technical notes, a "PowerPoint architect", I found him terribly lacking
any required skill (a sense of the many possible trade-offs, an ability
to deal with concurrency, etc.).
I even once witnessed one propose a network API to retrieve current time
in a "high performance computing" application, while calling system time
was perfectly fine (if not already a little slow).
But it's no surprise, since they got promoted to that authority position
by people who don't have a clue what it's all about, and for reasons like
having spent a few years coding a framework (whatever dirty it is), or
knowing a lot about what some old thing do and how it does it, or even just
due to age, look (but where does look not come into play? :), or diploma
(without any experience, just out of school, because the school was
"a top one" - was the case for the network API guy).

The problem with the clueless people (managers) is not so much that they
don't know what it takes to develop software, that they don't seem to know
what it takes to do anything, as if they didn't do anything real in their
lives and had some kind of magical thinking, which seems to be a tendency
in our societies with our serviced lives and the multiplication of
"bullshit jobs".

That reminds me of an old peasant woman I knew when I was a child,
she had not much education but made very good pies.
She often told us about urban people, with her accent:
"Les gens de la ville, quand mêêême, ils sont bêêêtes !"
("People of the city, reeeaally, they are stuuupid!").

That said, if the developers are good enough the architect might just
have to throw in some advice here and there.

What is architecture? by Ian Eshelman

Thanks for sharing. I completely agree with the assessment in the article.

The software development community does itself a huge disservice when we try to model development practices off of manufacturing. Too often we look at software architecture like manufacturing architecture and equate blueprints to UML or paper designs. What is completely missed here, is that while blueprints may very well be the design of the building, paper is never the design of the software solution. The code itself is the design, and the code itself defines the architecture of the solution. While manufacturing deals with very predictable materials such as wood and steel, the software process introduces so many variables and complexities that quickly supersede any "PowerPoint design".

Thus, any architects, that aren't involved at the code level, are depriving themselves or real design. This article does an excellent job of describing the void we create when allow, or even encourage, "architects" to stop coding.


Future of the architect by Vikas Srivastava

Very Good article and nicely presented, my only question is what is the future of an architect. Where and when does he fork himself from routine architect activity.
Technology keep changing he keeps learning and waiting for the opportunity to implement those technologies. If developer is struggling to learn and implement code and help them to learn and implement. He may never move up the ladder if he keep continue coding and keep helping. His whole achievement would be his value is recognized by team, many times he keep helping and delivery is keep delivering what is the further roadmap for the architect.
I have met couple of professionals who spend there whole life doing the same activity, they are known to be the god father for the product application at the end but what next...what is the future of an architect.

Extinct role by Andreas Meyer

In former days there might be some "architect" as described.
Nowadays architect should focus on requirements, test/quality, communication (with management and other stakeholders), and the coarse grained architecture - the main components.
Technology is nothing that architects could suggest, that is what they are asking for.
Architects do not "lead", they fulfil only a differen role compared to developers in a team.

Application and Solution Architects Maybe by Aaron Wakefield

As an Architecture Executive with many years of experience building Architecture Organizations for fortune 100 companies I think this post misses the mark.

This is a very narrow view or architecture. Architecture as a discipline is made up of many different families of architects which play very different, but equally important roles. Technology Architects, Platform Architects, Application Architects, Solution Architects, Security Architects, Innovation Architects, UX Architects, Business Architects, Enterprise Architects, Information Architects, etc. Some of these architects have 0 coding experience. Technology and Platform Architects as an example do not start out in development. The last thing I want one of my Enterprise or Business Architects to be doing is coding. I want them focused on business process engineering, capability mappings, and IT strategy.

Who do I want to code from time to time? Application Architects, Innovation Architects (maybe), Solution Architects (rarely). At the end of the day I can hire a lead developer for 30+% less than an architect. Also, in my experience lead developers have a very different mindset and it hinders them when they try and move into architecture roles. Change the title to 'Application Architects Should Code..... Sometimes' and we are square. As it is presented I don't agree.

Architects should know about coding.. by Peter Shacklock

But not necessarily be in the weeds with whatever language their developers use. Methodologies, structures, concepts, processes, yes.

Let the hordes of developers hoard that knowledge themselves.

Re: Almost fully agree by Brandon Bryson

In the situation you describe, working with a team of inexperienced developers, then, yes, the architect or tech lead may need to play a more driving role. But if you completely exclude the team from being involved in any the difficult implementations you risk developing a system that only you can support and missing an opportunity to provide those inexperienced developers some experience.

Re: Application and Solution Architects Maybe by Brandon Bryson

I see your point. The article was written with a software/application architect flair. However, the key theme applies to most all technical architects, be they application, infrastructure, integration, data, etc. Architects should be invested in the decisions and engaged in the delivery of the architectures they propose.

Re: Almost fully agree by Hermann Schmidt

You are right Brandon, that's why I wrote "watch and learn". Everyone who writes code must be collaborative and open. Coding architects should be a role model in terms of code quality and collaboration. This is what makes them valuable.

Re: Magical architecture by Richard Clayton

Well said. Met many of the same UML/PowerPoint architects with dated technical knowledge/skill. The only reason why they exist is because the organizations that have promoted them have an equally technically incompetent corporate staff.

Re: Application and Solution Architects Maybe by Hermann Schmidt

I think there is a difference between consulting architects and instructing architects.

The Instructor MUST have up-to-date programming skill, as he is directing programmers. I think most readers here have this type in mind.

The Consultant can quite happily not program, if his expertise is orthogonal to programming. For instance UI design. However, to avoid ivory tower work, a close collaboration and understanding what programming is about is still necessary.

Both need to understand the constraints of the target environment.

Software Architect’s Deliverables by Dariusz Nabialczyk

It’s very interesting article. However, the author didn’t mention architecture deliverables, which in my honest opinion, are the main factors which determine what architect should or shouldn’t do, act and behave. So, I’d like to understand what are the architecture deliverables envisioned by the author. Maybe dear readers can propose the list of such deliverables? All ideas are welcome.

Re: Almost fully agree by Mark N

This is a lead developer, not an architect. A lead developer does not always make a good architect.

Re: Extinct role by Mark N

Technology is what they should state should be used. Not suggest.

Re: Almost fully agree by Aaron Wakefield

I Agree

Re: Application and Solution Architects Maybe by Mark Webster

I understand the need to be engaged through the process. As Infrastructure Architects in out organization we are expected to work with Application and Integration architects to do the Infrastructure Architecture Architects, The do the technical infrastructure Solution Design and the the Detail Design or build doucument that is used by the SME's to build the solution.

We are being told that (re your Article) that Architects should code and I see from your note that you include the Infrastructure. Can you tell me what type of coding you would expect the Infrastrcuture Architect to do?

Thanking you in anticipation

Mark Webster
Infrastructure Solution Architect.

Architect Architect shouldn't code by Homer Najafi

When I got my last job as solution architect in a bank the hiring manager asked me the same line of questions (Do you code? When was the last time?). And I told him I don't and believe architects shouldn't code.
He gave me the job saying "You are right. We have 200+ programmers here making a portion of your salary. If we have programming needs we will go to them. We have 5 of you. Let them talk to you in your language (Charts, diagrams,...). Don't talk to them in their language (Code). Don't write code. Don't read code. Don't do anything with code."
He was right. We made the best software assembly-line I've ever seen (this was my job number 20). We were getting requirements from business. Convert them to architecture designs. passing them to dev team. well oiled machine. Still working perfect.


Email me replies to any of my messages in this thread


Email me replies to any of my messages in this thread

19 Discuss
General Feedback
Privacy policy