Should application architects write code?

Question

This is an often-asked question that has views on both side. Those in favour will argue:

• To design a system for coders you must understand how to code (and be coding)
• You can't design a system without being aware of what is happening at ground level
• Architecture is not just about broad stroke design but about adapting to changing needs at the code level

on the other hand,

• Architecture is a high-level role and should be not be concerned about implementation details
• Coding is a detailed oriented, heads-down funtion which is at odds with the risk management, broad view nature of architecture
• Architecture is about technical risk management and not implementation
• Architecture is about leadership. It's difficult to lead from behind

In my experience architects should not be spending a lot of time coding but must keep in touch with the code base primarily through lead developer communication, review and stand ups. If you spend a lot of time coding you lose sight of the high level issues and become ineffective at managing technical risk.

Answer 1

I wonder why nobody has mentioned the code reviews or pair programming which can replace coding.

I spend much more time reading the code and solving problems with my coworkers than coding. This give me almost the same understanding of the code, its structure and complexity as writing it myself and is much less time consuming. When I code, I do that for fun or to explore new technologies (This is the only place where I've found coding useful).

Answer 2

Since everyone here is a coder, the favourites gotta be the hells-yeah answer - and you'll get no disagreement from me.

But the finer grained answer is more correct in my opinion, because it appropriately values domain expertise. People who know little bout software, but just use it are so valuable.

How the architectural roles are divided up seems to depend on the size and nature of the organization.

If I had it my way, I'd give the client a role of Story Architect if they write good, useful, detailed stories and use-cases.

Answer 3

As Vlion stated, asking this question in a community overwhelmingly dominated by developers means the answers will be skewed towards "yes".

As somebody who has "architect" in his job title but who was also recently awarded the badge of "Distinguished Engineer", my loyalties are torn. In general, I think coding is not usually an effective use of an architect's time. So what should I be doing?

• Understanding the business.
• Understanding the systems used to enable the business.
• Working with the business on IT strategy and tactics.
• Making sure current projects are being done with a long-term view, where the project manager concentrates on the short-term view.

So how should an architect keep in touch with reality? I think by regular meetings and walkarounds, just talking to people at every level and oiling the wheels of communication.

Answer 4

This standard Developers answer is that an Architect should also be coding. But it's a kind of Developer that puts technology first. But I tend to disagree. Yes it's beneficial to have some coding skills, in order to be able to review the code.

But the only thing an Architect does is bring together the business requirements with the implementation. And in our case the code. If you have a seriously complex system, you cannot be coding and doing Architecture at the same time, cause you're operating at too many different abstraction levels.

Instead you should be able to rely on the Developers. They should be able to describe the aspects of the implementation, and how it fits in the business requirement that you have pointed out to them. What technology is chosen is the Architects decision, but to come to that decision he has to do research or use past experience. That doesn't mean he doesn't talk to the Developers, or let them investigate a specific technology to see whether the Architecture really works.