This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Effective Architects Code
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I had a discussion the other day with an architect who is just starting out. He asked me what makes an architect effective. After giving it some thought, this is what I answered.
The difference between an effective architect and one who isn't is that the architecture/design/technology guidance that the effective architect prescribes is implemented by the development team. And vice versa. Of course the architect isn't omniscient, and there will always be things that come up during development that render some of the guidance irrelevant, but for the most part the statement holds.
The question then becomes: well, how does an architect get the team to do what he says?
The answer, which has already been previously raised on the blogs, has to do with communication and persuasion. Since the architect doesn't really have any organizational power being outside the management hierarchy, he can't force anything. Chances are that if he tries, the team will just kick him out and the project manager, if forced to choose between the development team and an architect whose job he doesn't really understand anyway will almost always side with the team (and rightfully so).
Therefore, an effective architect has to be accepted by the team. This includes both the programmers and the team lead, a XOR is not enough. Programmers have to see the value in the designs handed down by the architect, while the team lead has to see that the guidance doesn't increase schedule risk - short term and long term.
What often happens when a programmer gets handed a design document from the architect? They take one look and say "That can't even be implemented. This architect is so out of touch with today's technology I just don't get why he gets paid so much." The first time this happens, there's a chance that the programmer will go to the architect and say that the design can't be implemented. An effective architect will go with the programmer to his workstation, take the keyboard, and show him the code to implement the design. Not necessarily all of it, but enough that the programmers says "OK, I get it". It's also of the utmost importance that the architect explains in what way this design/code is better than other alternatives - less dependencies, easier to test, etc. An ineffective architect would probably wave off the programmer saying "of course you can implement it. Just do what the class and sequence diagrams show."
The result of this will be that the programmer will now respect the architect who coded and would probably stop listening to the architect who didn't. This is critical when schedule pressure starts mounting. Programmers will continue to seek the guidance of the effective architect and will ask for his assistance in pushing back on the schedule pressure.
If the team lead sees that his programmers are more productive (as in feature points per unit of time) and have less bugs now that they are working with the architect, he'll also be more attentive to the architects suggestions. This keeps going up and up the chain of command, to the point where team leads and project managers actively budget and schedule for time with the architect. Other teams and projects will notice that the team who's working with the architect is more productive and successful than they are, and then they too will seek the architects guidance.
Effective architects create an environment of trust and collaboration with all stakeholders. But if the programmers on the front line don't have that as well, it just won't be able to grow up and out to the entire organization. And, from my experience, programmers will respect the code and not much else. So, an architect who can't code will have difficulty being effective.
Tell me what you think. Can an architect who doesn't code gain the respect of the programmers? If they can't, can they still be effective? What do you think is an effective architect?
Previous Topic
