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

Even if your argument against coding is valid, I think it's important for the dev team to respect you and your design decisions. If you "suffer the consequences" of your architecture decisions right along with them, then they're much less likely to question them.

All the time, I see architects who are out of touch with the coding side, and whose dev teams know it. They don't get much respect.

Answer 2

Ab-so-frickin-lutely

There's nothing worse than an Architect who has lost touch with reality.

It's part of the job to keep your feet on the ground and your head in the clouds.

Answer 3

I don't think that they need to be coding everything in the application. But they should be given some tasks. Some "architects" are basically hacks with no technical experience who pass themselves off as "legendary coders" and design systems that add weeks or months to the amount of work you would have had to do if you didn't have an architecture. If they can't write code they have no business being in that role...Because the idea is an architecture should make the application easier to develop and maintain. But if the architect cannot develop, how would he or she know how to make an architecture?

Also, even the best architects make bad decisions. Sometimes something looks great on the white board but then in reality an architectural decision ends up making things a lot harder than they should be. If the architect has to eat his/her own dogfood (and use the architecture) they are more inclined to want to correct bad decisions or to architect ways around them. Also by touching the code they are at least a little familiar with it. So if a developer comes to them with a coding issue, the architect's eyes won't glaze over as he/she dismisses the developer and says the developer is doing it wrong but offers no insight onto the right way to do it.

The architect doesn't need to be doing big projects within the code base. But they should at least be doing small tasks within the code base that force them to use their own architecture. Also the small tasks will probably involve reading a lot of other people's code to give them a sense for how people are using the architecture and whether anything can be done to improve it.

Answer 4

To the risk of deviating from the topic...

On a large scale application, it may not be possible for an architect to stay updated with the code being written. Also, it would not be possible for him to write the code because of other important responsibilities. Having said that, I would recommend, the architect should not loose the big picture about the code base being developed. This can be achieved by monitoring the code base for code coverage, metrics about code quality, static code analysis, etc. He should regularly assess the code quality using the mentioned criteria. The practices of 'continuous integration' can help here.

Answer 5

Every project I've worked on that has included an architect that did not spend a significant portion of their time hands on with the code has had problems because of that absence of hands-on knowledge.

That includes the projects where I was that architect :-)

It's now a personal big red flag.

I agree with all the arguments in favour of architects who code. The arguments against don't hang together well for me.

The code needs to abstract the high-level concepts as well as the low in an application. Unless the design and code are integrated at all levels the solution is going to be less than optimal.

As for "Coding is a detailed oriented, heads-down funtion which is at odds with the risk management, broad view nature of architecture" - in my experience a broad view - and risk management especially - make for better coders not worse :-)

"Architecture is about technical risk management and not implementation" - not it isn't. It's about risk management and implementation (and a bunch of other stuff).

"Architecture is about leadership. It's difficult to lead from behind" - why does coding put you behind? Personally I find that the best place to lead is with the people you're working with.

Answer 6

Some times, they have to code. For instance, when the team is only one person.

In my opinion, they can code if they want but must not lose the big picture. A no go is to change the designed structures every day.