Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!petsd!pedsga!tom
From: tom@pedsga.UUCP
Newsgroups: comp.software-eng
Subject: Re: program complexity metrics
Message-ID: <244@pedsga.UUCP>
Date: 22 Dec 87 17:35:57 GMT
References: <561@ndsuvax.UUCP> <3850002@wdl1.UUCP> <242@pedsga.UUCP> <392487e8.fed5@apollo.uucp>
Reply-To: tom@pedsga.UUCP (Tom Gillispie,7321)
Organization: Concurrent Computer Corp., Tinton Falls, N.J.
Lines: 24

In article <392487e8.fed5@apollo.uucp> marc@apollo.UUCP (Marc Gibian) writes:
>The current crop of complexity measures do NOT improve the code.  There . . .
> ----- summary of recent ACM article deleted -----
>
>The application of complexity measures at Raytheon, required by almost
>every software contract there, is usually accomplished by requiring that
>every module (however a module is defined) has a set of complexity values
>less than some arbitrary number.  Unfortunately, the process of reducing
>the measured complexity of a module most often decreased the quality of
>the module, made it harder to maintain, harder to understand, and generally 
>did not accomplish the intended goal.  I can provide specific examples if
>anyone is interested.

Marc states (very well) an important point, but I, for one, would like to
see some examples.  The phrase "the process of reducing the measured
complexity" worries me a bit.  The article Marc posted led me to beleive
that Raytheon has used the complexity formula to "reverse engineer" their
standard for software development.  Just because their particular standard
resulted in "decreased quality", does not mean there isn't a standard that
results in a high level of quality PLUS a favorable complexity value.
I have used the term quality to refer to the original article:
maintainability, readability.  It still makes sense that lower complexity
values would improve this quality.  I'm not sure that Raytheon's bad
experience disproves this.  It certainly bears further investigation.