Software-Quality Discussion List Digest #002 Tenberry Home Software-Quality Home Reducing Defects Automated QA Consulting Site Index

================================================================
           Software-Quality Discussion List

      S O F T W A R E - Q U A L I T Y   D I G E S T

         "Quality Techniques that Work for Us"
================================================================
List Moderator:                      Supported by:
Terry Colligan                       Tenberry Software, Inc.
moderator@tenberry.com               http://www.tenberry.com
================================================================
January 30, 1998                        Digest # 002
================================================================

====IN THIS DIGEST=====

    ==== MODERATOR'S MESSAGE ====

      We're off to a good start

      Term "bug" considered harmful

    ==== CONTINUING ====

      (Nothing yet)

    ===== NEW POST(S) =====

      (None -- come on, how about some posts?)

    ==== MODERATOR'S QUESTION ====

       How do YOU measure quality?



==== MODERATOR'S MESSAGE ====

      We're off to a good start

  In the first week, we have more than 115 members.  The original
  posting to NEWLIST had an error in it (how embarassing!), so
  the early subscriptions all had to be done by hand.  Just to
  be perfectly clear, mailto:software-quality@tenberry.com is
  for postings, while mailto:software-quality-join@tenberry.com
  is the subscription address.

  I fiddled with the NTList parameters, so that non-members of
  the list can get a list of files, and retrieve back issues.
  Also, Software-Quality now has a web page:

     http://www.tenberry.com/softqual

  It's still pretty sparse, but I would appreciate suggestions
  for what would be useful.


      Term "bug" considered harmful

  I don't like the term "bug" to describe software problems,
  because it implies that there is some (possibly malevolent)
  third party involved.  Since all (okay, virtally all) "bugs"
  are created by one of the programmers working on the software,
  using "bugs" suggests that 1) they are some basic force of
  nature; and 2) that they are inevitable.  The first idea
  is obviously false!

  The second idea, that software problems are inevitable,
  while a widely-held belief, seems to be false as well!
  Software problems are certainly common, numerous and
  seemingly endless, but in my studies of a few rare programmers
  who routinely produce software with no apparent "bugs",
  their single most striking characteristic was their denial
  that "bugs are inevitable"!

  Rather, these individuals believe that a "bug" in their
  software is as embarassing as belching at a fine French
  restorant, and should be supressed/avoided/prevented at
  almost all costs.

  When I first discovered this attitude, I thought it was
  quite odd -- since I was firmly in the "bugs are inevitable"
  camp.  However, these individuals are the most productive
  in their respective organizations, and since their error
  rates are so low that I can't measure them*, I've decided
  that their attitude works and have adopted it.

  Because of the results of these "take responsibility" folks,
  I prefer a term which places the responsibility on the
  programmers who create the problems.

  Therefore, I suggest we use the terms "error" and "defect",
  using "defect" most of the time.  When we need to distinguish
  between  problems found internally versus problems encountered
  by the user(s) of our software, we will use "defect" for
  anything the user encounters, and "error" for problems found
  internally before deploying our software.

  *(Note: for the individual I have studied the most, I can't
  say just what her defect rate is, since I've only got about
  350,000 line of code to measure.  Her error rate seems to be
  less than one per week, and with our very thorough QA process,
  her defect rate is less than one per year.  At her current
  rate, I can't tell what the defect per KLOC rate will be,
  other than less than 1 defect per 100 KLOC.)

  Comments?  Suggestions?


==== CONTINUING ====

  (No responses)


===== NEW POST(S) =====

   (No responses other than a SPAM advertisement for management
    consulting)


==== MODERATOR'S QUESTION(S) ====

  How do YOU measure quality?

  How can you tell that you and your organization is doing
  a good job on quality?

  How can you tell that you are doing better this year than
  last?

  Do you count the number of times the CEO threatens you?
    (fewer is better!)

  Do you count customer defect reports?

  Just how do you persuade some other party (like your boss
  or your customers) that you are doing well/better?


=============================================================
The Software-Quality Digest is edited by:
Terry Colligan, Moderator.      mailto:moderator@tenberry.com

And published by:
Tenberry Software, Inc.               http://www.tenberry.com

Information about this list is at our web site,
maintained by Tenberry Software:
    http://www.tenberry.com/softqual

To post a message ==> mailto:software-quality@tenberry.com

To subscribe ==> mailto:software-quality-join@tenberry.com

To unsubscribe ==> mailto:software-quality-leave@tenberry.com

Suggestions and comments ==> mailto:moderator@tenberry.com

=============  End of Software-Quality Digest ===============