Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!ukma!usenet.ins.cwru.edu!abvax!iccgcc.decnet.ab.com!kambic
From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.)
Newsgroups: comp.software-eng
Subject: Re:  use of metrics
Message-ID: <1991Jun13.174427.4861@iccgcc.decnet.ab.com>
Date: 13 Jun 91 22:44:27 GMT
References: <795@tivoli.UUCP> <35121@mimsy.umd.edu> <4794.284cfad3@iccgcc.decnet.ab.com> <35346@mimsy.umd.edu>
Distribution: na
Lines: 83

In article <35346@mimsy.umd.edu>, cml@cs.umd.edu (Christopher Lott) writes:
> In article <4794.284cfad3@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) writes:
>>Can you use metrics to determine if a person needs training?
> 
> I think you can invent a metric to determine, by your standards, anything
> you like.  But inventing one to determine if a member of your staff needs
> training is not going to win you any friends or cooperation among
> your technical staff.   My argument is that this is a wholly inappropriate
> use of a software metrics program.
OK - now justify it.  I am investing time and money in supporting this 
person doing it.  S/he is not doing it correctly because of lack of training
(theorectically).  Now, how do I as a manager justify waiting until I 
"know" the person needs training, and then how do I present it without
useful positive-looking information to back it up?
> 
>>>I write:
>>> It's naive to think that a group manager doesn't know already who are
>>> the stellar performers and who are already not so hot -- metrics, if they
>>> are given, will only confirm this knowledge. 
>>Mr Kambic writes:
>>How does the manager determine that in the first place?
> 
> You're leading me down a path that I can't quite see.  But here's a response.
> I have never managed people, so I can't place myself in that situation.
> However, in all my positions, I soon figured out who were the good workers
> doing good things and who were the average ones.  (is average pejorative
> in this group? ;-)  Surely the manager knows from previous experience who
> meets deadlines, 
A measurable date and deliverable.
> meets expectations, 
Software works, is testable
> produces work that doesn't need to be
> redone, etc.  
No bugs, customer satisfied, pays invoice.
> And they talk to their tech people who, in my limited 
> experience, seem to know each other's work pretty well.  
Peer review technique is very valuable and works well, but also has 
flavor of opinions over quantitation. 
>>Mr Kambic makes me work by writing:
>>Please explain how you separate software people from the software process. 
> 
> Clearly, this is a contradiction.  Thank you for bringing it up.  
> 
> I think people who discuss metrics programs all too often confuse the ROLE of
> the software person with the INDIVIDUAL.  The roles which people play
> constitute our work.  Individuals are then cast into these roles and told Go!
> So, I argue that when running a metrics program, we want to gather information
> about the processes (roles) which people perform and about the artifacts they
> produce, not directly info about the individual.  Only by focusing on the
> larger picture, the role and the process, can any organizational learning
> or improvement happen.
How do you select people for roles?  Not arbitrarily is absolutely true.  You 
select the right people.  But you have to know they are right.
> 
> The reasons for not evaluating individuals directly are manifold, but primarily
> for the success of the metrics program.  Put another way, we don't live in a
> perfect world.  If metrics are used for worker evaluation, the workers will
> respond immediately in ways to make the metrics show them in a favorable light.
> If no such pressure is exerted, they can afford to be honest.  When you're
I know all these points.  Let me ask a question I asked in another post.  
How are software people different from many other people in the world who 
are evaluated on quantitative metrics (sales, no. produced, etc.)?  Please 
elucidate.
> 
> I can invent any number of metrics scenarios in which people fake data to make
> themselves look better.  Lines of code for productivity?  Hey, blank lines!
> Effort to effect repair of a bug?  Hey, low-ball it!  Time spent on the 
> computer?  Uh, two or three runs, a few seconds, yeah!  Effort charged to
> the project?  What, you mean all those night hours I put in fixing my 
> screwups?  forget it!
Yea.  Now how we do convince people that if we are to make money we really 
do have to know these things.
> 
> A metrics program that evaluates roles/processes and products, and does not
> take any part in the worker evaluation process, has a chance. Once people 
> are convinced that the metrics program will benefit them, they'll be happy
> participants.  But it may be a hard sell.  (maybe I understate this point ;-)
Slightly!  8:-)

Fun.

GXKambic
Just try measuring this disclaimer