I was recently deep in an architecture process when I was asked by a team member for some help in understanding the team operating model. Or more specifically, a team leader and architect were asking me whether they should be coding a particularly difficult area of the system.
Being in architect mode, I immediately ran to the white board and architected the optimum software development team process. Here it is…
What I was trying to describe was the role at each level, which is achieved through experience, and the flow between them. So while an architect or team leader may be able to develop code at 3-5 times the rate of a Junior Programmer, everyone above can fill the roles below – but the reverse is not true. So if that architect is programming, no one is architecting!
And while the architect might be able to code without an architecture or design (because he or she has an image of it in his or her mind), if he (or she) does so there is no architecture or design for other programmers that come along in the future and have to deal with that code (maintain it, extend it, interface with it, etc).
When the senior people do this for base system components, they make a major team mistake that leaves everyone else struggling with their now undiagrammed undocumented features in the future.
It may get it done faster now, but it’s usually a mistake in the long run.