Xref: utzoo comp.software-eng:2599 comp.lang.ada:3026
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!vsi1!daver!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.software-eng,comp.lang.ada
Subject: Re: Design your "Dream" Metric/Metric Tool
Message-ID: <10816@goofy.megatest.UUCP>
Date: 1 Dec 89 02:23:38 GMT
References: <3305@jarthur.Claremont.EDU>
Organization: Megatest Corporation, San Jose, Ca
Lines: 47

From article <3305@jarthur.Claremont.EDU>, by ssdken@jarthur.Claremont.EDU (Ken Nelson):
> 
...
> 
>   Send me your spec for your dream metric and your
>   dream metrics tool.

  Oh, let me just ramble on here for a bit, okay?  (By the way, why is this
  posted to comp.lang.ada?)

>   What phase of the lifecycle, what aspect of code,
>   design, requirements etc... do you think is worth measuring, and how 
>   would you measure.  How would you present/use the information?
> 

I don't think I would ever take or keep a job where automated techniques
were used for more than collecting very general data. I'm not one to say,
"Machines will never do this or that."  I mean, _WE_ are machines, right?
And I must admit that somebody at the company is probably going to have
to decide how great a job I'm doing, even if he hasn't a clue. :-) But
every "software metric" program I have heard of is just out and out silly.
I imagine that I will be replaced by a program -- perhaps one that
I write? -- long before there is a program competent to judge the quality
of my programs.

As a starter, the program will absolutely need to read and understand the
program's functional spec, (or infer one if there is none), and decide to what
extent the program does what it is supposed to do. If you don't have a
good guess at that, you don't have anything. It should also take into
account such market considerations as cost of delayed entry into the market
versus the cost of user-discovered bugs. It should measure how well the
spec is implemented in terms of speed, size, accuracy. (Fast, small, and
bug-free are better.) It should know how to weigh these considerations,
knowing when bugs are disastrous, and when they are mere annoyances, when
speed is crucial and when moderate speed is plenty, etc..

A corollary is that no bonus should ever be given for _more_ lines written.
More _functionality_ is the goal, not higher disk usage. If functionality
and speed are constant, then _fewer_ lines is better. (I say this even
though, if you can believe what's been written here lately, my own
lines-of-code output over the last year is well over twenty times the norm.)

Style-checkers that count goto-statements, depth of loops, etc.. are
virtually worthless. If somebody's style is so bad that such a simplistic
program can figure out that it's bad  -- dubious premise -- then somebody
should be helping him to improve it. Code like that should never be judged
as a final product.


Brought to you by Super Global Mega Corp .com