Re: programmer productivity.

If your programmers know that you measure productivity by LOC then the
measurement is useless.

How do you distinguish between cut & paste lines of code vs new lines of
code.  Modified lines of code vs lines where only the
spacing/capitalization was changed ?  

I can modify all of the lines of a program in no time at all. 

I have seen the following:  (as I am sure everyone else here has too)
(pseudo code)

if Row = 11 and column = 10
 exsr   prompt
 goto   again
endif

if Row = 11 and column = 11 
 exsr Prompt
 goto again
endif 

... for all 10 columns of the field

very productive !!!

if Row = 11 and column >=10 and Column <=19
   exsr Prompt
   goto again
endif

Well this re-write was very un-productive !!!

On the other hand if you measure bugs then who decides which programmer
is responsible for the bug ?

If you ever have telco problems don't be suprised if the problem is
fixed and the technician reports "no trouble found"  I am told this
relates to their performance rating.

There is a dilbert cartoon where the pointy haired boss offers $25 for
every bug found ... Wally declares "I'm going to write myself a
mini-van"

Project delivery and quality control is the only measurement of
productivity.  The problem with that is we don't know how to estimate
how long it should take to complete the project!!!   And who decides
what is a quality/bug issue and what is a revision.

John Hall


Richard Jackson wrote:
> 
> Alan:
> 
> I can find no end of documents to show that no other productivity-measuring
> system offers a substantial advantage over LOC.  Note, I am not saying that
> LOC is good only that nothing else is much better.
> 
> One does not compare LOC across languages.  As you pointed out, that is a
> silly idea.
> 
> Since you have attacked LOC is such an "involved" way, would you like to
> suggest a method that you believe will work better so that we may attack
> you?
> 
> <bg> (I'm not very committed to this discussion)
> 
> Measuring productivity is a pretty silly idea too.  If you believe that you
> can measure productivity using a simple technique that is easy to understand
> then you also believe that programmers perform mechanical work and that they
> should be a commodity item.  Good luck filling programming positions.  If
> you are willing to accept that the job is complex and technical then you
> must also accept that the measurement technique will be complex (subject to
> interpretation) and you will not understand what the programmer is doing.
> When you don't understand it, at least part of the time the measurements
> will not make sense.
> 
> The OP should monitor each fix through its lifetime.  Fixes move through
> stages defined by a process model.  Status reporting identifies where each
> work order is in the process.  Allow management to understand how long each
> stage should take and how long it actually did take.
> 
> Richard Jackson
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---