Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!abvax!iccgcc!kambic
From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.)
Newsgroups: comp.software-eng
Subject: Re: Software Quality 2.0
Message-ID: <4347.28158f77@iccgcc.decnet.ab.com>
Date: 24 Apr 91 19:00:22 GMT
References: <1991Apr2.200958.8208@spool.cs.wisc.edu> <36650003@hpopd.pwd.hp.com>
Lines: 23

In article <36650003@hpopd.pwd.hp.com>, daves@hpopd.pwd.hp.com (Dave Straker) writes:
> If a person is introducing more bugs, then you help him produce
> less, in a non-threatening manner. He probably knows, more than anyone,
> that he's screwing up, and is feeling pretty guilty about it anyway.
> So, the manager privately and carefully investigates. The guy may
> be having personal problems (so give him some space). He may be unskilled
> in areas he is working on (so train him). He may just be being careless
> or be trying to do to much (so slow him down and get him to check).
> In the end, it comes down to man-management. If there *really* is no other
> answer, then take him off coding. There are many other activities in
> software engineering.

You have just used metrics to evaluate a person.  Justify that in the light 
of quotes from Humphrey about not using metrics information to evaluate a 
person.  BTW, not trying to put you on the spot here, but this situation 
seems to me to be a very real problem.  You are measuring a process that 
intimately involves real people doing real things.  How are these different
from time management studies that purport to help a person to define and do 
their job better (and maybe sometimes actually do).  The process is not 
separate from the people doing it.

GXKambic
standard disclaimer