Cindy Bogle wrote:
> Release to Release our quality has been improving at a very good rate.
> Within IBM we are required to project code quality by using "defects per
> thousand lines of code (KLOC)" measurement.  We do projections when
> planning new releases, based on new code we will develop.   In the first
> version of ADSM-  V1 we were experiencing 1.3 defects per KLOC.
> Progressively at each delivery we have been improving, for V3 we had >
projected .5 and in reality we are achieving significantly better
> quality in the < .2 range.  For EM we projected .15 defects/KLOC.  Any
> defect in the code is bad, but our results demonstrate
> we are continuously improving.  Benchmarking ADSM against other products
> like it, shows us ADSM is one of the leaders in code quality.

A quality metric based purely on the number of defects implicity treats all
defects as being equally important. This has a very real potential for
encouraging misplaced priorities.

Consider two bugs that have been discussed on this list:

1.A query command used the wrong default value for one of its parameters. This
could be circumvented by specifying the documented default value explicitly
when executing the query.

2.Backup files installations intended to keep were silently discarded (the bug
that triggered this exchange of mail).

A quality control system based purely on counting defects would count
prevention of either of these bugs as equally important accomplishments. If
reducing user interface glitches like the first bug happened to be easier than
reducing data integrity problems like the second bug, such a system would
actually encourage development managers to focus the resources available to
them on user interface glitches rather than data integrity issues.