This chapter is from the book
This chapter is from the book
This chapter is from the book
There Are Certain Limits
It is a matter of common sense that a software organization cannot increase or decrease the core metrics without limits. Can we ascertain what those limits are?
The metric that above all others is subject to limits is development time. There is always pressure to get a system out faster. Yet if you try to develop a system in too little time, you will fail, sometimes at great cost. It seems reasonable to suppose that there is some minimum development time. You can’t complete a system in less than this time, as we discuss further in Chapter 5. The length of this minimum time varies with the size of the system, the area of application, the skill of the developers, and the development environment provided by management. So, is there a way to find out for a particular proposal what this time is?
Yes, and it involves keeping the core metrics on each project. This historic data enables you to find out what your minimum development time is on a system for which you have at least a rough size estimate. This minimum time is good to know. If you get pushed into a schedule at less than the minimum development time, you are automatically set up for at least a schedule failure, very likely a product of less reliability than a reasonable schedule would have produced, and possibly an outright project failure.
Regrettably, if you choose to operate your project at the minimum development time (assuming you have the data to make this choice), you are also locking yourself into two negatives. One is that the effort needed will be at a maximum. Consequently, the cost will also be at a maximum. The second negative is that reliability is proportional to development time, so it too will be at a minimum.
More happily, there is a favorable trade-off between development time and effort. If you can extend the development time beyond the minimum time, you can greatly reduce the effort. Similarly, reliability improves. The amount of this reduction in effort or improvement in reliability is based on the knowledge provided by the basic metrics.
At the other end of the development time scale, there is no fixed maximum development time. Of course, organizations seldom worry about setting that end. Still, beyond about 130 percent of the minimum development time, the trade-off between time and effort lessens sharply, as we illustrate in more detail in Chapter 11. There is little economic point to extending development time beyond 130 percent of the minimum development time. A reasonable schedule lies in the middle of this range, longer than the minimum development time, but short of the maximum development time.
Thus, in software development “small is beautiful,” meaning fewer developers over a longer time allowance resulting in a more reliable product. Data on 491 projects from the QSM database confirms this belief, as we report in Chapter 11. Briefly, dividing the projects into two categories, small and large, revealed that the small teams took much less effort at each system size than the large teams.
At this early point in the book, we can only state conclusions like these without providing the supporting details. In Part II, though, we establish more fully the five core metrics and the relationships between them. Then, in Part III, we begin to make use of these relationships in planning projects. By Chapter 11, for instance, we will have the background that will enable us to pursue the “power of the trade-off and the “small is beautiful” themes in depth.