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.