Excerpted from Pitfalls of Object-Oriented Development by Bruce F. Webster, pg 62-63. Copyright © 1995 Bruce F. Webster. All rights reserved. Reproduced here by permission of IDG Books Worldwide, Inc.
Once, while discussing the challenges of object-oriented development with Taligent trainer Tom Affinito, I mentioned -- citing Fred Brooks -- the need for a chief architect (see Pitfalls 4.13 and 4.14). Tom immediately responded, "Yes, and ultimately architecture is a political act." Unless you are both sole architect and sole implementor --- and maybe even then -- architecture is a political act, and it is especially true in development groups of any size. Developers like to think themselves above politics. Not so; they are as human as anyone else. Developers can be quite political and will use a variety of techniques, good and bad, to achieve their ends: persuasion, hyperbole, fear-mongering, caucusing, lobbying, consensus building, rumors, backbiting, leadership, intimidation, sacrifice, tantrums, threats, and subversion, to name a few. The fact that developers are generally very bright just increases the effectiveness of whatever techniques they use. Architecture is the lodestar of developer politics because it is ultimately the most prestigious role in software development. Brooks does to great lengths (and rightfully so) to assert the intellectual and creative challenges of implementation, but it is Frank Lloyd Wright's name that remains attached to the structures he designed, not the name of the contractors who built them. Or, to update an old programming joke, the verb "to develop" is conjugated this way: "I architect, you implement, he tests." Yet we may fail to recognize or acknowledge this situation and its implications. Why? First, we want to believe that all developers have (with regard to the project) the same intentions and goals. Second, we want to believe that the best course is the one that is obvious to us and that everyone else will agree with that. Third, we don't want to have to deal with politics ourselves, particularly politics that can lead to confrontations. *Symptoms* Assuming that all other developers have the same goals, ideas and talents. Not wanting to assert architectural issues. Finger-pointing as design problems arise. *Consequences* Hidden or overt team dissension, leading to poor morale and lack of cooperation as well as a weakened architecture. *Detection* Ask yourself these questions: - Who is the chief architect of this project? - How well do the other developers support the chief architect? - How effective is the chief architect in her role? - What are the obstacles she faces? - What are all the political issues involved? Answering these questions should go a long way toward determining whether you have underestimated the politics of architecture. *Extraction* The first issue to address is that of authority commensurate with responsibility: If there is a chief architect on the team, does she really have the authority to compel adherence to the architecture? This kind of authority is different that being able to say, "Do this or you're off the project," which often leads to subtle or overt rebellion by team members. This kind of authority accrues from several factors: - a proven track record - respect from teammates - [s]upport from technical and upper management - a mutual pact with the developers that the chief architect will give serious consideration to all their ideas and suggestions but that they will abide by her decisions - a willingness to give in on the small things so that she can hold her ground on the big things Beyond that, healing a team that is experiencing jealousy and dissension is no easy feat, especially when you're in the middle of a project. Books and seminars on team-building abound; study, learn, and apply. *Prevention* Go through the questions in *Detection* but cast them in the future tense. Then, as with *Extraction*, proactively work to build the team and establish the authority of the chief architect.
The only typo I corrected was s/upport/support/. The others are mine.