Michael Jackson (the singer, not the computer scientist) sang that "One bad apple don't spoil the whole bunch, baby." That might be true for apples, but it isn't true for software. One bad apple can spoil your whole project.

A group of ITT researchers reviewed 44 projects in 9 countries to examine the impact of 13 productivity factors on productivity (Vosburgh et al. 1984). The factors included the use of modern programming practices, code difficulty, performance requirements, level of client participation in requirements specification, personnel experience, and several others. They divided each of the factors into categories that you would expect to be associated with low, medium, and high performance. For example, they divided the "modern programming practices" factor into low use, medium use, and high use. Figure 3-1 on the next page shows what the researchers found for the "use of modern programming practices" factor.

The longer you study Figure 3-1, the more interesting it becomes. The general pattern it shows is representative of the findings for each of the productivity factors studied. The ITT researchers found that projects in the categories that they expected to have poor productivity did in fact have poor productivity, such as the narrow range shown in the Low category in Figure 3-1. But productivity in the high-performance categories varied greatly, such as the wide range shown in the High category in Figure 3-1. Productivity of projects in the High category varied from poor to excellent.

Figure 3-1. Findings for "Use of Modern Programming Practices" factor (Vosburgh et al. 1984). Doing a few things right doesn't guarantee rapid development. You also have to avoid doing anything wrong.

That projects that were expected to have poor productivity do in fact have poor productivity shouldn't surprise you. But the finding that many of the projects expected to have excellent productivity actually have poor productivity just might be a surprise. What this graph and other graphs like it throughout the book show is that the use of any specific best practice is necessary but not sufficient for achieving maximum development speed. Even if you do a few things right, such as making high use of modern programming practices, you might still make a mistake that nullifies your productivity gains.

When thinking about rapid development, it's tempting to think that all you have to do is identify the root causes of slow development and eliminate them—and then you'll have rapid development. The problem is that there aren't just a handful of root causes of slow development, and in the end trying to identify the root causes of slow development isn't very useful. It's like asking, `What is the root cause of my not being able to run a 4-minute mile?' Well, I'm too old. I weigh too much. I'm too out of shape. I'm not willing to train that hard. I don't have a world-class coach or athletic facility. I wasn't all that fast even when I was younger. The list goes on and on.

When you talk about exceptional achievements, the reasons that people don't rise to the top are simply too numerous to list. The Giga-Quote team in Case Study: Classic Mistakes made many of the mistakes that have plagued software developers since the earliest days of computing. The software-development road is mined with potholes, and the potholes you fall into partially determine how quickly or slowly you develop software.

In software, one bad apple can spoil the whole bunch, baby. To slip into slow development, all you need to do is make one really big mistake; to achieve rapid development you need to avoid making any big mistakes. The next section lists the most common of those big mistakes.