Some Tough Questions

One reason that new innovations move into practice slowly is that some of them don't work very well in practice! Not all innovations are useful, and the Early Majority, Late Majority, and Laggards have some good reasons for being cautious. When presented with an innovation, they ask tough questions like these:^[23]

• Do experimental results prove conclusively that the innovation will work in practice?

• Are successes a result of the innovation itself, or might they be the result of the people using it?

• Is the innovation complete, or does it need to be adapted or extended before it can be applied?

• Does the innovation have significant overhead (training, documentation) that offsets its value in the long run?

• If the innovation was developed in a research setting, does it apply to real-world problems?

• Does the innovation generally slow down the programmers?

• Can the innovation be misapplied?

• Is information available about the risks involved with using the innovation?

• Does the innovation include information about how to integrate it with existing practices?

• Must the innovation be applied in its entirety to realize significant benefits?

Very few software engineering practices have had data collected and disseminated widely enough to prepare software practitioners to answer questions like these. As a result, the software engineering practices described in Table 21-1 are stuck on the left side of the chasm. Early Adopters have been using many of those techniques for 15 years or more, while the later adopter groups are largely unaware of them. The numbers from Rogers's adopter categories are close to the numbers of projects that use code-and-fix development about 75 percent of projects are still using code and fix or its close cousins, and a similar percentage of adopters fall onto the right side of the chasm.

Why is this? In Rogers's framework, one reason that innovations are diffused to Innovators and Early Adopters more quickly is that Innovators and Early Adopters tend to have more resources they are in better positions to afford costly mistakes. Later adopters are more cautious partly because they aren't as resource rich. As I mentioned in Chapter 12, however, the scarce resource in this case isn't money; it's time. Lagging-edge practices such as code-and-fix development are associated with significant schedule overruns. The overtime that usually accompanies such overruns doesn't leave time for investigating and adopting more effective innovations.