Xref: utzoo comp.software-eng:2499 comp.misc:7471
Path: utzoo!attcan!uunet!samsung!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Programmer productivity
Message-ID: <16186@duke.cs.duke.edu>
Date: 24 Nov 89 17:18:11 GMT
References: <16170@duke.cs.duke.edu> <34819@regenmeister.uucp>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Distribution: na
Organization: Duke University CS Dept.; Durham, NC
Lines: 108

In article <34819@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>From article <16170@duke.cs.duke.edu>, by crm@romeo.cs.duke.edu (Charlie Martin):
>> In article <34796@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>>>Are there metrics to measure the productivity of electronic engineers?  
>>>No?  
>> Sure there are.
>>>Then how about measuring the productivity of mechanical engineers?  
>>>Another blank? 
>> Nope.  Happens all the time.
>>>Perhaps they measure the productivity of civil engineers 
>>>some way?  No again?  
>> Sorry, but civil engineers as well.
>>>Perhaps a pattern can be seen here.
>> Yes, I do think you're right: there is a pattern.  It obviously isn't
>> the one that you expect.
>
>Perhaps I over simplified.  I was referring to objective measures
>commonly used by competant professionals.  I was not referring to
>hypotheses that have never managed to escape academia.  Sorry to have 
>confused you.
>

Chris, do you have any, like, *evidence* that what you are saying is
true?  Which civil engineers have you quizzed?  What books on management
of design have you read?  If there is some evidence to what you are
saying I'd like to hear it.

But empty assertions and sneers aren't argument, nor do I count your
assertions as being more meaningful than mine because you currently work
at a company while I currently attend college.

On the side, I'll bet 58 cents I was programming for a living before you
graduated from high school.  

>The term metric is generally taken to mean a number arrived at by a
>completely "objective" and simple algorithm.  I believe lines of
>finished code per day were mentioned in the posting to which I
>responded.

I can't *imagine* a more objective and simple algorithm than that used to
count lines of code in most places I've worked.  "Number of non-blank
lines" was common.  "Number of non-blank, non-comment lines" was also
common.

It fulfils all the mathematical definitions of a measure, I believe
(forgive me that I don't dig up Halmos's book to check.)

Yes, the algorithm can be circumvented: someone can write a C statement
in a form like
	x = \n 3 \n + \n 4 \n ;
and in theory get 5 lines credit of a simple statement.

But -- you work for Sun, you tell me -- would you get away with that
kind of crap in your code, independent of the question of productivity
measures?  I sure hope not.  When my friends who had single-digit badge
numbers at Sun worked there, you certainly could not.

The source line of code measure is used precisely BECAUSE it is simple
and objective (see e.g. _Software Engineering Metrics and Models_, Conte
et al., or _Software Engineering Econonics_, Boehm.)  One reason it is
objective is that it presumes that the source code being counted fits
other constraints on its form that constrain away pathological cases
like the above.  This is the same reason that the "unroll the loop"
argument won't work: if you unroll 'for(i=1;i<10000;1++)' into 10,000
separate statements, you are not going to make friends with your
manager.

>
>First, I did not say, nor imply, that there was no way to estimate a
>project.  There is one and it is commonly used in each of the fields I
>listed as well as in software engineering.  Estimation of engineering
>projects is a complex process that is practiced effectively by only a 
>small percentage of the more senior professionals in most engineering
>fields.
>

Sorry, but that appears to be exactly what you did imply.  Estimating a
project is not something that only a small percentage of most senior
professionals do; even a first-line manager or a senior programmer does
it in software engineering.  There is indeed a way to estimate a
project; in most fields including software engineering, it comes down to
something like "how many things (SLOC, drawings, components) will it
take to build one of these?  How long does it take us to do a thing?"

Thing counting and empirical models based on previous experience are
precisely the way other fields do it; it's the way it is done in
practice in software engineering.  Source lines of code has been a
useful measure BECAUSE within standards it works; empirical models based
on SLOC fit predictions nicely to production, AND turn out to correlate
strongly with every other model that is also predictive.  (This really
isn't much of a surprise if you think about it.)  These empirical models
of productivity seem to be what you claim is not well founded or does
not work.

Why then are they predictive?

>I claimed, and still do, that other fields of engineering do not attempt
>to fool themselves with simple minded numbers.  Every project lead and
>manager "measures" the productivity of the staff working with him/her.
>That measure is one's self.  One estimates how long a task would have
>taken one to do, adjusts for assumed relative competance, and compares
>that to what has actually happened.

And I clain, and still do, that only fools think that SLOC is a simple
minded number without empirical support.  Are you a competent software
engineer?  Do you know what the state of practice in software
engineering is?
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)