[mmatants]

It makes sense to have centrality of vision for how code should be laid out. This is software architecture (as skill and role, not title though!). And as people have a limited focus span, it makes sense to segment - by business topic, by API, etc. But of course fiefdoms emerge.

In some ways, it might then almost be better to not have that person contribute to same codebase: to avoid ego pissing contests and to keep the opposing pressures in balance. The pressures being: delivering features on time on one hand, and keeping things clean and orderly on the other hand. Often, if the architect codes then they can't see their own mistakes, but have 20/20 vision of others' grubby flaws, and hence gain subconscious animosity towards external contributions.

That being said, an architect who does not code is even worse! This is where we get ivory tower Architect-as-title, and even less gets done. I wonder what the optimal middle ground is.

[davidjnelson]

Perhaps the middle ground is a software architect who codes, yet has high emotional intelligence and acts as a servant leader. Someone who honestly wants to help their teammates, and doesn't feel "better than them".

Perhaps they lay out a system design as a suggestion on a wiki and ask their teammates including themselves to collaborate on it until everyone's content with it.

Then perhaps they code a particular layer primarily and are humble and open to criticisms and mistakes they make in their own coding. They understand that they and others are not perfect, nor is the code they or others produce.

That and good relationships and communication with the product, design, management, qa, and support teams are what I feel would define a valuable "Software Architect".