This chapter is from the book
This chapter is from the book
This chapter is from the book
The Limits of the Possible
Thus, software development is in trouble, not for trivial reasons, but for deep-seated ones. An understanding of the role the five core metrics play is the first step in getting out of this trouble. These metrics are related to each other, as we suggest pictorially in Figure 4-1 and as we will develop in more detail in Part II. In the meantime, however, we can draw these general conclusions:
- If we want to get more work product (that is, more functionality, measured by some metric of size), we have to increase the amount of effort, lengthen the development time, or improve productivity. Of course, we could also augment some combination of effort, time, and productivity.
- If we want a product of higher reliability, that, too, takes increased effort, lengthened development time, or improved productivity, or some combination of the three increases.
- Conversely, if we want to reduce effort and/or time, we would have to limit the functionality of the product (reduce its size), accept less reliability, or increase productivity. We note, however, that productivity remains about the same in the short run, such as the time scale of a single project.
- If we improve productivity (over a fairly lengthy time period, of course), we can achieve more functionality or more reliability at the same level of effort and time.
- With improved productivity, we can reduce effort and time and still achieve the functionality or reliability originally intended.
With substantially improved productivity, we can achieve even higher levels of the other four metrics.
Figure 4-1: Each little gnome (or concept) has to possess the strength (measured by a metric) to support the next higher level.
)
Unfortunately, better productivity does not come with the snap of executive fingers. Our records of more than six thousand projects over two decades show that productivity gains come slowly, sometimes not at all. The average gain for the business projects in our database was 8 percent per year and for the more complex engineering and real-time systems, several percentage points less. In the final years of the twentieth century, the record shows even less gain.
Productivity gains at these rather low levels are not going to produce the miracles that the devotees of Internet time hope for. However, in comparison with the general level of productivity gain, these software gains stand out. Only in the final years of the twentieth century did the productivity gain of the United States economy as a whole reach 3 or 4 percent; for decades, it had been stuck just above 1 percent. Then, in the early years of the new millennium, it fell back to the 1-percent range again. The software industry, or at least the parts of it reporting their core metrics to us, has done well.
The industry’s problem, really, is to find the way in which it can make the “Faster, Better, Cheaper” mantra work. We can divide that problem into three sections:
- We have to accept the reality that the five core metrics are interdependent, as we discussed in Chapter 2. Only productivity gains get us to all three of the “Faster, Better, Cheaper” goals simultaneously.
- We have to actually do the things that bring about those gains. The interdependence of the core metrics does not, by itself, put best practices into effect. It does not manage projects skillfully. It does not inspire developers. It does not work smoothly with stakeholders.
We have to accept the necessity for metrics—at least the five core metrics and the relationship between them.
- They make planning and estimating dependable.
- They provide the basis for management control during project execution—the comparison of actual numbers against the planned numbers.
- They provide evidence that the organization is actually making the productivity gains for which it is striving. That evidence, then, encourages management to continue the effort.
At best, however, productivity gains occur over the long run. Management often has to do what it can in the short run. Realizing that getting all three—faster, better, and cheaper—in the short run is impossible, managers can focus on maximizing the one or two metrics they consider urgent in a particular case:
- If you want to get a software product out faster (in effect, reducing time), you can increase the number of people (that is, effort) assigned to the project. You can also increase the quality of that effort by assigning better qualified people to such projects. Alternatively, to achieve faster, you can sacrifice reliability, that is, spend less time getting the requirements straight or keeping them current, take little time for analysis and design, speed up coding, skip inspection, and reduce testing; in other words, release an inferior product. It is clear that a lot of software projects have gone this route.
- If you want to get a better software product, that is, one with more functionality or more reliability, you have to allow more time or effort. With more time, that is, by spreading the same amount of effort over a longer schedule, a smaller staff can do a better job. With more effort, that is, by packing more effort into a shorter schedule, an enlarged staff can build the product in less time. But you can’t indefinitely reduce either effort or time—there are limits, as we note in the next section.
- If you want to develop a software product cheaper, in effect, with less effort, you can reduce the emphasis on faster or better. First, you can extend the time: A smaller team over more time will get the job done at less overall cost. Second, you can skimp on better. As the wag said, “If you don’t set a specification for the product to meet, I can give it to you next week.”
Table 4-1 summarizes the relationships among the five core metrics.
Table 4-1: The only way you can fulfill the “Faster, Better, Cheaper” mantra—all at one time—is to improve productivity. As the final column indicates, improved productivity (upward arrow) provides gains in all three mantra goals. The other four columns show mixtures of gains and losses. For example, the first column, Time, reports that, to go faster, you have to reduce time. To get better or cheaper, you have to increase time.
Mantra |
Time |
Effort |
Reliability |
Size |
Productivity |
Faster |
↓ |
↑ |
↓ |
↓ |
↑ |
Better |
↑ |
↑ |
↑ |
↑ |
↑ |
Cheaper |
↑ |
↓ |
↓ |
↓ |
↑ |