From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_20,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 19 Sep 93 22:47:23 GMT From: agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso l!strohm@ucbvax.Berkeley.EDU (john r strohm) Subject: Re: Automated Ada Physical Source Lines Counter Message-ID: <1993Sep19.224723.5441@mksol.dseg.ti.com> List-Id: In article <27ga4t$13m@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes: >In article , muts@compi.hobby.nl (Peter Mut saers) writes: >> >> Who needs number of lines as a metric anyway. Completely useless IMHO >> and only used to impress managers who don't know a thing on software >> development. > >This issue is discussed periodically on the software engineering >bulletin board. The really annoying thing seems to be that despite all the >perfectly-reasonable QUALITATIVE arguments about why LOC should NOT >be a useful measure of anything (notably effort), it appears >to have some rather strong EMPIRICAL correlation with effort. That >is, if one can estimate LOC, one can estimate effort to within 10k% >for small k, at least within a given organization. Don't ask me why; >I don't pretend to know. This is a very important point. LOC as the basis for software estimation WORKS, when used within an organization that has taken the trouble to calibrate the estimating process. Depending on how it is done, it works somewhere between fairly well and very well. At least one large company routinely bets the company bottom line on software estimates based off of a LOC estimate. Exercise for those who have time for exercises: Derive a software metric that is easily measured, easily estimated, useful for software estimating, and is NOT strongly correlated to LOC. That last requirement is the sticking point: most of the usual alternative metrics have been shown to be strongly correlated to LOC.