Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!marick
From: marick@m.cs.uiuc.edu
Newsgroups: comp.software-eng
Subject: Experiences with Defect Prevention
Message-ID: <39400109@m.cs.uiuc.edu>
Date: 27 Jun 90 13:58:00 GMT
Lines: 48
Nf-ID: #N:m.cs.uiuc.edu:39400109:000:2187
Nf-From: m.cs.uiuc.edu!marick    Jun 27 08:58:00 1990


You should read this:

"Experiences with Defect Prevention".  Mays, et. al.  IBM Systems
Journal, Vol. 29, No. 1, 1990.

Abstract:

"Defect prevention is the process of improving quality and
productivity by preventing the injection of defects into a product.
It consists of four elements integrated into the development process:
(1) causal analysis meetings to identify the root cause of defects and
suggest preventive actions; (2) an action team to implement the
preventive actions; (3) kickoff meetings to increase awareness of
quality issues specific to each development stage; and (4) data
collection and tracking of associated data.  The Defect Prevention
Process has been successfully implemented in a variety of
organizations within IBM, some for more than six years.  This paper
discusses the steps needed to implement this process and the results
that may be obtained.  Data on quality, process costs, benefits, and
practical experiences are also presented.  Insights into the nature
of programming errors and the application of this process to a variety
of working environments are discussed."


Three things attract me about this process:

1.  Often, the recommendations of software engineering pundits are
global and revolutionary.  Many ignore the need for gradual, steady
process improvement.  Consequently, you get far too many prescriptions
like "Throw AWAY that error-prone C code!  DISPENSE with your
investment in training and tools!  Paradise lies just beyond the
learning curve!"  and far too few comments like "You can reduce the
number of misused-equal-sign errors in C if you make the habit of
writing all your tests as 'if (CONST = var)', rather than the other
way around".  This technique helps you discover what you can improve
while you're waiting for the revolution that we all hope will come.

2.  The recognition that the way to do things better is to think hard
about what you do wrong.  Obvious, but it doesn't happen unless
it's made to happen.

3.  The recognition that grovelling in your errors won't be effective
unless there's time set aside to implement solutions.

Brian Marick
Motorola @ University of Illinois
marick@cs.uiuc.edu, uiucdcs!marick