Xref: utzoo comp.software-eng:2567 comp.misc:7526
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!ctrsol!emory!mephisto!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Programmer productivity
Message-ID: <16272@duke.cs.duke.edu>
Date: 30 Nov 89 20:56:47 GMT
References: <16186@duke.cs.duke.edu> <11825@cbnews.ATT.COM>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Distribution: na
Organization: Duke University CS Dept.; Durham, NC
Lines: 57

I didn't include the article I'm replying to because I'm too lazy to do
a good job of cutting it.  I don't think I'm taking any liberties with
the reasoning, but if I did, just let me know.

I think there is a hangup between "is an objective metric" and "is a
GOOD objective metric."  I claim SLOC as an objective metric in the
sense (1) that it is objective because when I give an exact and
effective description of SLOC, I'll get the same count every try, and
anyone else who uses the exact an effective description to count with
will also get the same count every try, agreeing both with counts from
observation to observation and between observers; and (2) that it has
the properties we associate with a metric mathematically (essentially
that it is additive and obeys the triangle inequality).

I'm pretty well aware of the various paradoxes of SLOC; I used to argue
this from the other side before I changed my mind.  The reason I changed
my mind is that over a large number of observations and a long time,
the figure "5--10 source lines of code per staff day" has stood up
quite well.  Even stood up under the change between assembler and
HOL's.  

(One thing about this sort of figure is that it is natural to read this
as meaning "they only write 10 SLOC a day and that is it" when the
observation is instead 

	total source lines of code
	------------------------------  ~= 10
	total staff hours over project

Naturally one writes more that 10 SLOC a day; the remainder of the time
is spent writing all the other stuff, reviewing it and testing it.)

Given approriate weightings derived empirically, SLOC seems to
lead to a model that is predictive, with both testable time/cost
estimates and testable error margins (admittedly large) that can be
verified.  More oddly -- and I don't UNDERSTAND this, I've just
OBSERVED it -- things like Halstead and McCabe don't seem to do a lot
better job than SLOC based models do.  Halstead in particular seems
only to be predictive in the areas and under the conditions that SLOC
is predictive.  Many of the paradoxes of SLOC have analogous paradoxes
in other metrics (like the confounding examples for cyclomatic
complexity.)  Most of these things are anywhere beween harder and LOTS
harder to compute, but don't seem to model any more effectively.

For all of these reasons, SLOC (and the others) aren't very good
metrics.  I only use any of them because I know of nothing better, and
they allow me to estimate eith reasonable accuracy (including knowing
what the error margin may be, and when my modles are of no use.)
metrics.  

The original assertion wasn't that these are not good metrics -- all I
could say then is "have you got something better?  May I have it?"  It
was instead that it was meaningless to even assert that productivity
metrics could be defined or used.


Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 


Brought to you by Super Global Mega Corp .com