kww@cbnews.ATT.COM (Kevin W. Wall) (11/23/89)
Before we are all at each other's throats arguing how programmer productivity
should be measured, I suggest you all check out the book "Programming
Productivity" by T. Capers Jones (1987 ??). It points out the many apparent
paradoxes of using SLOC as a metric for measuring productivity -- most of
which are very non-intuititve. It is the ONLY book that I've seen on software
metrics which I think contains the STRAIGHT SCOOP (i.e., no hype) on this
crucial area. I highly recommend it.
Now getting back to SLOC, let's face it -- the general reasons that SLOC still
being used as a measure of programmer productivity are:
1) management demands some quantitative measurement (& rightfully so).
2) SLOC is a very easy thing to measure.
3) other possible software metrics (e.g., Halstead's, McCabe's,
function points, etc.) are either difficult to calculate, or
difficult to interpret, or both.
I assume that most readers of this newsgroup are well aware of the shortcomings
of using SLOC as an accurrate software metric. (If not, see T. Caper Jones'
book, mentioned above.)
Instead of pointing out are the things that are wrong with SLOC, how about
hearing some success stories using some other software metric (e.g., McCabe's
complexity metric, etc.).
Also (surprise, surprise), not all of software development consists of
programming. That is just the implementation phase. What metrics do you
use (or "should be used") for measuring productivity of those involved in
design, testing, requirements, etc.?
--
In person: Kevin W. Wall AT&T Bell Laboratories
Usenet/UUCP: {att!}cblpf!kww 6200 E. Broad St.
Internet: kww@cblpf.att.com Columbus, Oh. 43213
"Death is life's way of firing you!" -- Hack rumorcrm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)
In article <11690@cbnews.ATT.COM> kww@cbnews.ATT.COM (Kevin W. Wall,55212,cb,1B329,6148604775) writes: >.... >I assume that most readers of this newsgroup are well aware of the shortcomings >of using SLOC as an accurrate software metric. (If not, see T. Caper Jones' >book, mentioned above.) > >Instead of pointing out are the things that are wrong with SLOC, how about >hearing some success stories using some other software metric (e.g., McCabe's >complexity metric, etc.). > The funny thing about the other measures (e.g. McCabe and Halsted) is that they don't seem to be a lot more predictive than weighted SLOC models like COCOMO. Also, just like SLOC, they can be confounded by pathological programs: Elliot Soloway has a perfectly hilarious comparison of two programs with the same McCabe complexity, but where one is instantly and obviously much harder to code or maintain than the other. (This was done by choosing odd names, odd loop bounds and array indicises, that sort of thing. Another example of a way to confound McCabe or Halstead is programming with variable names like O0OO0.) >Also (surprise, surprise), not all of software development consists of >programming. That is just the implementation phase. What metrics do you >use (or "should be used") for measuring productivity of those involved in >design, testing, requirements, etc.? There is plenty of work to be done in this, no question. Common assumption is that, given the time for the whole thing guessed by SLOC, you can then guess the time for a phase by taking a proportionate slice of the total for that phase. But those time to complete SLOC rules of thumb, like 3-4 SLOC per staff day, represent total time to complete, not just implementation. Another good book on software engineering metrics is the Conte, Dunsmore and Shen book _Software Engineering Metrics and Models_. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)