Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!watson!ssdken
From: ssdken@watson.Claremont.EDU (Ken Nelson)
Newsgroups: comp.software-eng
Subject: Re: How do you measure code quality?
Message-ID: <7658@jarthur.Claremont.EDU>
Date: 28 Jun 90 22:04:51 GMT
References: <DON.ALLINGHAM.90Jun22081624@hendrix.FtCollins.NCR.COM> <10865@netcom.UUCP> <CIMSHOP!DAVIDM.90Jun25103758@uunet.UU.NET> <11113@netcom.UUCP> <926@gistdev.gist.com>
Sender: news@jarthur.Claremont.EDU
Reply-To: ssdken@watson.Claremont.EDU (Ken Nelson)
Distribution: comp
Lines: 28


  I am not sure that any metric is an absolute indicator of quality, 
  or even a close estimate all the time.  I also don't really care,
  as long as the metric gives me a general, accurate a lot of the time
  estimate of quality.

  I use metrics to prevent bugs, and to optimize and focus my
  maintenance and testing efforts.  If a high McCabe Complexity
  generally indicates bugs, then it only makes sense to allocate
  more design review, testing, checking out effort to modules
  with high complexity.

  Metrics won't replace users feelings about quality, or 
  programmers feelings about quality.   They can act as an
  CONSISTENT and IMPARTIAL consultant when merged with user's
  and programmers gut feelings can make the bug prevention
  and detection effort more efficient.

  Metrics don't have personal, political, or other problems
  generally associated with people.  They can be measured
  at night, on as small or large a piece of the software
  as you like.  Just like computers, they HELP but don't
  replace humans.


			Ken Nelson
			Software Systems Design
			(714) 624-3402