Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!usc!ucsd!casbah.acns.nwu.edu!accuvax.nwu.edu!delta.eecs.nwu.edu!travis
From: travis@delta.eecs.nwu.edu (Travis Marlatte)
Newsgroups: comp.software-eng
Subject: Evaluating programmers
Summary: Not by quantity of code.
Message-ID: <16580@accuvax.nwu.edu>
Date: 1 Feb 91 00:59:24 GMT
References: <13120@hacgate.UUCP>
Sender: news@accuvax.nwu.edu
Reply-To: travis@delta.eecs.nwu.edu (Travis Marlatte)
Organization: Northwestern U, Evanston IL, USA
Lines: 26

I have seen this several times, and it always confuses me. There is always
someone trying to evaluate a programmer by measuring the quantity of the
code produced. Besides the obvious means of subverting the measruing
technique, a larger issue is at hand.

We openly use production line quantity figures for evaluation - at least
as a prize winning incentive. The goal is to have a person working at
a production line station who can do the job faster than anyone else.

Why do we want to associate this same mentality with producing software?
I have never heard anyone suggest evaluating civil engineers by counting
the number of bridges they produce per day. Or, counting the number of
ICs designed in a circuit per day. Or, ... You get the idea.

I don't think that I am wrong to say that quality is the higher goal -
always has been - for other engineering fields. A manager or supervisor
usually has a pretty good feel for the quality of work produced. Also
important are the other attributes of a worker. Does that person interact
well with others? Take responsibility? Have initiative? etc.

I don't see that it is or should be any different for software professionals.
I do view software production as a sequence of steps. Each one requiring
different talents. But all need creative energy that counteracts the
effect of measuring output quantity.

Travis Marlatte