Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!emory!att!cbfsb!cbnewsc!bwf
From: bwf@cbnewsc.att.com (bernard.w.fecht)
Newsgroups: comp.software-eng
Subject: Re: Code inspections
Keywords: inspection, software engineering
Message-ID: <1991Jan29.183227.21331@cbnewsc.att.com>
Date: 29 Jan 91 18:32:27 GMT
References: <40530@genrad.UUCP> <7362@tekchips.LABS.TEK.COM> <29653@mimsy.umd.edu>
Organization: AT&T Bell Laboratories
Lines: 22

In article <29653@mimsy.umd.edu> cml@tove.cs.umd.edu (Christopher Lott) writes:
>
>Of course people must be judged on the quality of their work - but
>define software quality for me  ;-)  

It meets customer expectations.

But I think I agree with Chris's answer.  Certainly a programmer needs
to be evaluated based on their output, but process meters cannot be the
sole source for evaluating the programmer or else the process won't
be followed (or it may be "tricked" into showing things that are not
real.)  Some would even say that NO process meters should be used, which
may be true.  I'm sure there are plenty of indicators available that
have nothing to do with the "process".

Another argument is that process meters usually show "faults leaked
from one stage to another."  These indicators evaluate the process
and the team's ability to run it.  No single programmer should be held
accountable for a buggy module in the field -- many have been involved
in getting that module out there.  Even the most obvious indicator
to me, ie. maintainability, is a team job and is not likely to be the
result of one person's work.