Architects almost always come from successful development backgrounds. And they should remain as developers, i.e. keep coding on the non-critical path of the project in order to not to become a stranger to the development perspective.
However, this more often than not leads to a situation that the architect is regarded as a “superdeveloper”. In other words, you will rarely find any good developers besides the architects.
This situation leads to negative consequences on both the architects’ and developers’ part:
- The architect is increasingly constrained to development, and even to tasks on the critical path, as she is the best one to do it. So she cannot fulfill her other architectural duties, and the team is left without an architect.
- It doesn’t scale: The team will have few architects. And you won’t find any superdevelopers besides the architects. So the team is limited to few (if not one) superdevelopers.
- Most importantly, this situation kills the motivation of the developers. It will be assumed that the superdeveloper architect knows how to do their jobs better than they do. So there will be no room for the developers to exhibit mastery or exercise autonomy[1]There is an excellent book by Dan Pink explaining the role of mastery, autonomy and purpose for motivation and here a fun video summarizing it. within their given area. Who would like to work in an environment where someone can micromanage you anytime?
The main difference between a developer and and an architect is not that the architect is a better developer, but that the architect needs to take into account multiple aspects, including relations to other subsystems as well as non-technical aspects such as business.
In short, it would be more helpful for the team to adopt not the “architect as superdeveloper” anti-pattern, but the “architect and superdevelopers” pattern, where the architect has the overarching view of the system, and each developer is the master of her domain, much more than the architect ever can be.
For large-scale SW, an intermediate layer is present: architects between senior architect and developers. A similar relationship should hold between the senior architect and the architects, where architects master their designated area deeper than the senior architect, but refer to the senior architect in order to keep in sync with the big picture incl. business aspects.
Like in all anti-patterns, there are reasons why the “architect as superdeveloper” pattern gets adopted in each specific team setup. For example, the architect might not want to leave her comfort zone she established as a developer. And dealing with the underlying reasons is the key to eliminate or avoid this anti-pattern. What do you think, what other reasons could there be for the adoption of this anti-pattern?
Footnotes
↑1 | There is an excellent book by Dan Pink explaining the role of mastery, autonomy and purpose for motivation and here a fun video summarizing it. |
---|
Very nice post;)
Thx for the encouragement!
I have got your point and I do agree with you.
All the super-developers go become an architect or a technical lead just after they became a super-developer. So, this is leading an architect to work with non-super-developer or be a super-developer where possible. Maybe this is due to economical flip side of the technical roles. Maybe we should also discuss, do we need super-developers? Aren’t all developers super-developers?
I’d like to believe that all developers can be super at least in a specific domain. On the other hand, we shouldn’t forget what Brooks mentioned in the Mythical Man Month that programmer productivity can vary up to 10x.
About the economical flip side, you’re completely right. Somehow the money should be off the table, so people can make decisions based on more important factors. Thankfully programs for compensating expert developers sufficiently are increasingly becoming common.
Thank you very much for the feedback.