Key Principle: Minimize the Defect Detection Gap

ABOUT THIS CHAPTER   “If you can’t find the time to do it right, where will you find the time to do it over?” has been a mantra in quality-focused organizations for generations. The means used to “do it right” have steadily evolved, and modern Agile development has contributed some useful practices.

We don’t usually think of it this way, but defect creation is a constant on software projects. For every hour the development team works, some number of defects are created. Thus, graphing the cumulative defect-insertion line on a software project is essentially the same as graphing the cumulative effort line.

In contrast with defect insertion, defect detection and removal are not functions of general effort. They are functions of a specific kind of effort: quality assurance (QA) activities.

As the top part of the illustration below shows, defect detection and removal significantly lags defect insertion on many projects. This is problematic because the area between the two lines represents latent defects—defects that have been inserted into the software but haven’t been detected and removed. Each of those defects represents extra bug-fixing work that is rarely “on plan.” Each of those defects represents work that will unpredictably extend the budget, extend the schedule, and, in general, disrupt the project.