LOC Lines of Code debate

LOC Lines of Code debate

[Eric C Aker]

I just have to get in to this debate.
When I was working for a major airplane company some years ago all of
the programmers were told to give a LOC count in each weakly (sic) 
report. Of course a tool was written to automatically count lines and
give differences from last week. We all grumbled and one of the
programmers came up with this great analogy.

"Measuring progress on a SW project in lines of code is like measuring
progress on an airplane in pounds of aircraft designed. Would any
serious manager ask his aircraft designers how many pounds of airplane
did you design this week? It is true that after the aircraft is done
you can compute productivity in pounds of aircraft per manday, but it
is not a very useful number."

LOC Lines of Code debate

[Eric C Aker]

I just have to get in to this debate.
When I was working for a major airplane company some years ago all of
the programmers were told to give a LOC count in each weakly (sic) 
report. Of course a tool was written to automatically count lines and
give differences from last week. We all grumbled and one of the
programmers came up with this great analogy.

"Measuring progress on a SW project in lines of code is like measuring
progress on an airplane in pounds of aircraft designed. Would any
serious manager ask his aircraft designers how many pounds of airplane
did you design this week? It is true that after the aircraft is done
you can compute productivity in pounds of aircraft per manday, but it
is not a very useful number."

Re: LOC Lines of Code debate

[George C. Harrison, Norfolk State University]

In article <"910326054349.71660.412.CHE55-1"@CompuServe.COM>, 71660.412@CompuServe.COM (Eric C Aker) writes:
> I just have to get in to this debate.
> When I was working for a major airplane company some years ago all of
> the programmers were told to give a LOC count in each weakly (sic) 
> report. Of course a tool was written to automatically count lines and
> give differences from last week. We all grumbled and one of the
> programmers came up with this great analogy.
> 
> "Measuring progress on a SW project in lines of code is like measuring
> progress on an airplane in pounds of aircraft designed. Would any
> serious manager ask his aircraft designers how many pounds of airplane
> did you design this week? It is true that after the aircraft is done
> you can compute productivity in pounds of aircraft per manday, but it
> is not a very useful number."

Excellent analogy!

The problem is measuring the progress of an intellectual product.  LOC is often
used in management metrics; they, after all, have to be concerned about the
bottom line.  

The problem as I see it is that often LOC measure very little.  In many cases,
of course, there is a relationship:  a 100,000 LOC program is probably more
difficult and complex than a 1000 LOC program.  There are some good empirical
studies out there to suggest this.  However, we've all written programs that
are several hundred lines long - including design, testing, etc. in a few
hours, and we've written 40 LOC that may have taken weeks to develop and test.

So, the question remains (and I'd like to have some answers for my Software
Engineering class)....  What is a good measure of programmer productivity?

(The only one I can think of is the amount of coffee/Mountain Dew/JOLT consumed
per hour.)

-- George C. Harrison                              -----------------------
----- Professor of Computer Science                -----------------------
----- Norfolk State University                     -----------------------
----- 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
----- INTERNET:  g_harrison@vger.nsu.edu ---------------------------------

Re: LOC Lines of Code debate

[Robert I. Eachus]

     How about the number of documented decisions made? (I'd count
undocumented too if I could figure a reasonable way to do so.)  One of
the reasons I find that "productivity" in non-comment LOC is so much
lower in Ada package specifications, is that the interface (and stated
listed pre- and post- conditions make the actual implementation of
many bodies no brainers.  Use of a design language like Anna or Byron
should make it fairly easy to pick up and count such decisions.

     A simpler approximate measure (for well written Ada) is the
number of declarative items, since each type, task, subroutine, or
object declaration tends to embody about the same number of design
decisions.  (Poorly written code on the other hand tends to have lots
of "junk" variable declarations--many often unused.)


--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...