Pitfall: Not recognizing the politics of architecture

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: political, architectural, managerial

While discussing the challenges of software development with Taligent trainer Tom Affinito back in the mid-1990s, I mentioned — citing Fred Brooks — the need for a chief architect. Tom immediately responded, “Yes, and ultimately architecture is a political act.”

That observation has stuck with me ever since. 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 goes to great lengths (and rightfully so) to assert the intellectual and creative challenges of implementation, noting that architecture is not the be-all and end-all. Still, 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 — without verification — that all other members of the development group 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 than 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
• support 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.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.