A stitch in time saves nine,” the old saying goes. “An ounce of prevention is worth a pound of cure.” In software, these expressions translate into the common observation that the longer a defect stays in process, the more expensive it is to fix.1 Industry reports about the magnitude of the cost increase have varied over the years. The highest ratio I’ve seen published came from Barry Boehm and Philip Papaccio in 1988.2 They reported that requirements defects that made their way into the field could cost 50 to 200 times as much to correct as defects that were corrected close to the point of creation. Of course, “50 to 200 times” is a rough average, and in the worst cases, the sky is the limit for defect costs—literally. The US space program had two highprofile failures in 1999: in both, correcting a defect “in the field” was not possible, and the software errors that went undetected until the software was in the field ended up costing hundreds of millions of dollars. I’ve previously presented a rough rule of thumb that early, upstream defects generally cost 10 to 100 times as much to remove late downstream as they do to remove close to the point where they are created.1 These observations have been used to justify a focus on upstream quality assurance activities such as extensive requirements work, design work, and technical reviews. These old sayings and rules of thumb have come under attack in recent years. Some people claim that software defects aren’t as expensive to correct as they used to be; costs don’t increase as quickly as they used to. In other words, an ounce of prevention is not worth a pound of cure, but perhaps only an ounce of cure.3 Some claim that we are expending more effort on prevention than we would by fixing the defects later—that we’re spending a pound of prevention to avoid an ounce of cure.
[1]
R. R. Willis,et al.
Hughes Aircraft's Widespread Deployment of a Continuously Improving Software Process
,
1998
.
[2]
Capers Jones,et al.
Applied software measurement (2nd ed.): assuring productivity and quality
,
1996
.
[3]
Steve McConnell,et al.
Rapid Development: Taming Wild Software Schedules
,
1996
.
[4]
Dick Bowman,et al.
Principles of software engineering management
,
1989,
APLQ.
[5]
Capers Jones,et al.
Assessment and control of software risks
,
1994,
Yourdon Press Computing Series.
[6]
Marvin V. Zelkowitz,et al.
Principles of software engineering
,
1979
.
[7]
Kent L. Beck,et al.
Extreme programming explained - embrace change
,
1990
.
[8]
Barry W. Boehm,et al.
Understanding and Controlling Software Costs
,
1988,
IEEE Trans. Software Eng..
[9]
Capers Jones,et al.
Applied software measurement: assuring productivity and quality
,
1991
.
[10]
T. Capers Jones,et al.
Estimating software costs
,
1998
.