Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!usc!ucsd!sdd.hp.com!hplabs!hpfcso!mike
From: mike@hpfcso.HP.COM (Mike McNelly)
Newsgroups: comp.lang.c
Subject: Re: Re: Determining C Complexity
Message-ID: <7060008@hpfcso.HP.COM>
Date: 8 Aug 90 16:10:56 GMT
References: <1050@ashton.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 27

We may all be missing a point here:  Complexity metrics seem to be an
attempt at PREDICTING software quality, not a very useful way of
MEASURING it.  Once the product's out, it's silly to measure quality
indirectly via complexity metrics when there are more direct measures.

Personal $.02:  Any measurement technique can be subverted and sooner or
later it will be if it's employed as a stick by management against the
developer.  The measurement tools can be effective when they're used as
aids by the developer and not as rating systems. When the rules of the
game are set by metrics (or by any other means) pretty soon everyone
of any intelligence learns to play by the rules. It does not necessarily
follow that better products will be produced, only that these products
will conform to the "guidelines".

Example:  Bug reports in databases.  They're good until someone gets the
bright idea to use them as a lever for salaries, etc.  Then what happens
when the developer finds a bug in his own code?  He keeps a private list
of these bugs.  Is he really rewarded for finding bugs?  For other bugs,
his tendency is to downgrade them.

Example:  Code size (larger or smaller) as a metric.  As an aid in
prediction I suppose it might have its uses but as a guideline for
performance measurement it stinks.  The obvious result of such a
guideline is uninspired code.

Mike McNelly
mike@fc.hp.com