Should Architects Code?

If you are agile and agility is about getting closer to code, then you--the architect--should be coding with the development team, right? And if your not, are you simply sitting in an ivory tower and without any real knowledge about the project? Or as Michael Stal puts it in his blog on the architect's role:

Implementation Expertise: Architect always implements. That basically means, "eat your own dog food". An architect must product designs that can be implementable software architecture. And she or he must be able to refactor when necessary. Thus, an architect needs to participate in implementing and unit-testing....

I don't subscribe to this point of view. I believe that if architects take part as developers in the team, they will get bogged down with the gory details of detailed design and implementation. They will have trouble (deadlines, deadlines) lifting their head enough to see the big picture or pay attention to the problems in other areas of the developed software.

I do think that the architect should be part of the development team, but in the role of architect--act as a mentor, lead the architecture design, contribute (or at least review) designs, and participate in (selected) code reviews.

I also strongly agree with Simon Brown's view that the architects should posses coding skills as well as understand and have a good handle on technology.

Architects should be able to--and often needs to--create prototypes both to prove their point as well as a way to communicate it.

On small projects, it might be possible for a person to take two roles; for instance, work under the architect role as well as code in a developer role. However, in such cases it would probably be more beneficial for the company to get the architect to work on more projects and share their expertise, rather than limiting their contribution to a single project.

Posted by Arnon Rotem-Gal-Oz at 04:24 PM  Permalink