Re: SLOC-wars

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Halstead may have defined a number of metrics, but the one that seemed to be
discussed here was one for measuring volume of source code. I don't recall
the definition (someone help here?) but it had to do with looking at the
operators and the identifiers in a body of source and coming up with a
number that tried to reflect the semantic content.

Even though it is an after-the-fact number (as you rightly observe) it is
still useful. "How big was this project relative to that project?" "If I
have 10 programmers churning away on a large body of code every day, how
much of it are they impacting in a given month?" "If I give those
programmers faster workstations do they churn out more code in a given
month?" All those sorts of questions can be looked into to some extent by
being able to count up code volume - hopefully in a way that is less subject
to artificial manipulation.

All these sorts of metrics have their flaws - which we could debate
endlessly - but its still worth collecting some anyway in order to hopefully
advance understanding of the software development process & improve quality
& productivity.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:f6a580bb517ec9eced2eaa01cf9c9525.48257@mygate.mailgate.org...
>
> But I thought (with no expertise here) that the goal of stuff like
> Halstead's metric was that you could estimate it at specification time,
> and do foresight forecasting with that estimate.  I'd shudder to think
> what the accuracy of foresight guesses at SLOC from similar projects
> might accomplish in setting milestone dates and such.
>