Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!donm
From: donm@margot.Eng.Sun.COM (Don Miller)
Newsgroups: comp.lang.c
Subject: Re: Determining C Complexity
Summary: Metrics for fun and profit
Keywords: metrics
Message-ID: <140003@sun.Eng.Sun.COM>
Date: 2 Aug 90 01:03:38 GMT
References: <3205@mica6.UUCP> <1050@ashton.UUCP> <142@srchtec.UUCP> <2592@dataio.Data-IO.COM> <1990Jul26.165322.2729@zoo.toronto.edu>
Sender: news@sun.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 45

In article <1990Jul26.165322.2729@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <2592@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
>>In my experience, metrics are completely useless...
>
>I concur.  Code metrics, like line counts and structure charts and a zillion
>other programming fads, are an attempt to substitute rules and procedures
>for adequate resources and competence.  Bureaucrats cling to the belief
>that this approach can be made to work, even in the face of overwhelming
>evidence that it doesn't, because adequate resources are expensive and
>competence is difficult to assess and costly to retain.  TANSTAAFL.
>-- 
>NFS:  all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology
>and its performance and security too.  |  henry@zoo.toronto.edu   utzoo!henry


Better late than never with a rebuttal, I suppose.  

There's no arguing that substituting metrics, or any other
"rules and procedures", for adequate resources and competence
is not a good software development strategy.  Although I'm
not a bureaucrat, I cling to the belief that the use of metrics
during the software development process does work.  

To some extent, I'm reminded of the wise and talented American 
auto worker of the 70's, dismissing the statistical process
improvement methods (i.e. metrics) with the view that nobody 
beats the talented, creative, hard-working American labor force.
Apparently, Japan didn't hold the same view.  Japanese auto makers
have used metrics to improve product quality to superior levels.

Granted, cars aren't software.  Software, on the other hand, is
a product, no matter how "non-assembly line".  The software 
market is just beginning to become one in which quality can be
used as a distinct competitive advantage.  Thus, an attempt to
measure software quality with an eye toward continuous improvement
seems a rational course.

Please feel free to throw opinions at me.  I am very interested
in the impact of quality processes on the software development 
process.

Don Miller
Software Quality Engineering
Sun Microsystems, Inc.
donm@eng.sun.com