Re: Automated Ada Physical Source Lines Counter

[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)]

In article <27ga4t$13m@agate.berkeley.edu> hilfinger@CS.Berkeley.EDU writes:
>In article <MUTS.93Sep17095542@compi.hobby.nl>, 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.