71660.412@CompuServe.COM (Eric C Aker) (03/26/91)
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."
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (03/28/91)
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 ---------------------------------
eachus@aries.mitre.org (Robert I. Eachus) (04/01/91)
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...