A Consultant's View

Prairie Trail Software, Inc. ............................................................. November 2005

Pressure Programming

The project is late. So, what do you do? Programmers talk about "death march" projects - where either the project dies or the programmers die. Long hours, insane meetings, cold pizza, and warm beer. Is this the way things get done in your shop?

Many years ago, the book, "The Mythical Man Month" hit computer managers right where they live- their concept of how to manage development projects. It demonstrates how the common management tactics of the time (asking for heroic hours, adding people to a project, and breaking the project up over as many people as possible don't work. Although these tactics do work with manual labor, they do not work with knowledge labor.

A recent study by Quantitative Software Management duplicated the earlier study. It showed that adding people to a project makes things worse.

Two teams of different sizes did the same development. In the end, a 20 person team took 12 days less than a five person team, but spent $ 1.8 million more to do the same project. What made for the difference?

In knowledge work, the connections between people are more important than the individual knowledge and skills of one person. Adding one person to a team of 5 people adds six connections to the network of the team. Adding more people adds more connections. Typically, we humans can't handle more than 5 to 7 other people in a team. Thus, adding more people breaks down how well we work.

So, in large teams, people are designated to have the job of simply keeping the connections working: project managers, team coordinators, etc. Yet, a large team, just can't be as efficient as a small team.

The result is that a team made up of more people makes a lot more mistakes. In this study, the larger team made six times the number of bugs than the smaller team. The larger team also had to spend much more tirne going back and fixing things that were not done right. Communication of what was needed simply couldn't be done as well as in a smaller group.

On television shows like American Choppers or Overhaulin', we see small teams building fancy equipment or rebuilding an old car. None of these take large teams. They couldn't. A large team would take too long to figure out how to manage and run.

In a small group, people can talk to each other instead of relying on specifications (which are always incomplete). They talk to each other, draw pictures on the wall, and communicate how best the team should work. One company, known for its skill in developing, has a conference room for every 5-10 developers.

The essence of programming is not in writing code, it is in discovering what needs to be done. Programming is an exploration process that requires strong communications between the members of the team.