Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!uw-beaver!cornell!oravax!klapper
From: klapper@oravax.UUCP (Carl Klapper)
Newsgroups: comp.object
Subject: Re: ada-c++ productivity
Summary: Machiavelli as productivity expert
Keywords: Looking for a few lazy men
Message-ID: <2260@oravax.UUCP>
Date: 18 Mar 91 15:55:59 GMT
References: <1991Mar15.224626.27077@aero.org> <4921@ns-mx.uiowa.edu>
Organization: ORA Corporation, Ithaca NY
Lines: 59

In article <4921@ns-mx.uiowa.edu>, csq031@umaxc.weeg.uiowa.edu writes:
> Lines of code per day is an absurd measure at best.  Using it in contracts
> is just a way of lulling people who care about such things into thinking
> that programmers (and software companies) know what they're doing and
> that their output is quantifiable.
> 
> The actual situation (as most people know) is that when you set out to
> write something non-trivial, that hasn't been done already, you're
> much more like Lewis and Clark setting out in canoes than you are like
> a machinist putting a block of steel into the lathe. This scares the
> living shit out of bean counters.

There are, however, many cases where the productivity of the job which 
the program assists can be estimated, with and without the program.
The (presumably positive) differential of productivity with the program
over productivity without it provides an economically valid measure
of the value of the program. Expressing this measure in percentage terms
would remove any bias related to the volume of usage and thus provide
a measure of the productivity of the programmers over the life of the project.
Dividing by the number of hours spent on the project provides a measure
of hourly productivity.

In simple terms, "the ends justify the means" so we ought to measure
the value of the end result rather than the number of keystrokes, the number
of lines of code. This will also "scare the living shit out of the bean 
counters" because it is a post hoc measure. That is, managers of computer
programmers will still have to take risks and can only moderate those risks
by knowing thoroughly their project's task and tools. Only after the scores
come in will they know whether their team was good.

I do not mean to suggest that this measure is easy to calculate.
It should include code maintenance in the before and after use measures;
but, in most cases, time spent on maintenance can only be guessed.
Separating the programmers' contribution from that of the platform
could prove difficult. Assessing the indiviual contributions of project
members is an unwieldy task, though this might be ameliorated by dividing
the work into modules and only allowing one programmer to work on each module.
We will have to devise multipliers for reusable modules written on the project
and estimates of the value of those modules where they have been inserted.
Finally, the productivity of the job which the program assists may be hard
or impossible to measure, and the program could even create new uses 
for itself.

I only claim that this measure, which I may style the "Machiavellian measure",
makes economic sense whereas the LOC productivity measure plainly does not.
In fact, LOC are a liability, not an asset, a use or even abuse of resources
rather than a useful product. We would not reward a chef for the number
of lines in his recipe, but a program listing is just a recipe. For the chef,
the proof is in the pudding. Surely, for the programmer, the proof is in
the execution and use of the program.

+-----------------------------+--------------------------------------------+
|  			 _    | Carl Klapper				   |
|  Love Your Mother.	(_)   | Odyssey Research Associates, Inc.	   |
|                      earth  | 301A Harris B. Dates Drive		   |
|  Sell your car.	      | Ithaca, NY  14850			   |
|  			      | (607) 277-2020				   |
|                             | klapper@oracorp.com			   |
+-----------------------------+--------------------------------------------+