Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Determining C Complexity
Message-ID: <1990Aug2.195825.29393@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <3205@mica6.UUCP> <1050@ashton.UUCP> <142@srchtec.UUCP> <2592@dataio.Data-IO.COM> <1990Jul26.165322.2729@zoo.toronto.edu> <140003@sun.Eng.Sun.COM>
Date: Thu, 2 Aug 90 19:58:25 GMT

In article <140003@sun.Eng.Sun.COM> donm@margot.Eng.Sun.COM (Don Miller) writes:
>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...

Couldn't prove it by me, considering the absolute garbage that is usually
shipped, and the marketdroids' fixation on new features, as opposed to
making the old ones work.  I would *hope* for such a change, and have
been known to pointedly suggest it to certain companies, but I'm not
very optimistic.

>Thus, an attempt to
>measure software quality with an eye toward continuous improvement
>seems a rational course.

Certainly.  What does that have to do with code metrics?

That is the crux of the problem:  there is little or no evidence that
those code metrics measure anything *useful*.

If you want to measure quality, measure quality.  Count verified bug
reports and performance problems, and perhaps introduce some sort of
modifier for memory consumption.  These are not terribly good measures
of quality, but at least they measure real problems!

(If you want a suggestion on what to *do* with that information, forget
Japan for the moment and apply a dose of capitalism.  Start with the
number 1 at the beginning of the quarter.  Every time you get a legitimate
report of a flaw -- bug, performance problem, etc. -- multiply the
current number by 0.99.  At the end of the quarter, each person in
the programming group gets that fraction of his salary as a lump-sum
performance bonus.  Note that this applies across the whole group, not
person-by-person, which encourages cooperative efforts to reduce the
flaw rate.  And yes, this means that a very low flaw rate means paying
those people a lot of extra money -- they'll be worth it!)

(There are obviously a lot of details that need ironing out, and the
classification of things as flaws has to be done by some independent
assessment group, and it would be better to have an additive scheme
that lets people get *more* than 100% bonuses, but the general
point is clear, I think.  Do this and you can forget about silliness
like imposing code-metric testing on everyone -- the programmers themselves
will figure out which quality-improvement schemes work and which don't.)
-- 
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry