Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven.umd.edu!mimsy!cml From: cml@cs.umd.edu (Christopher Lott) Newsgroups: comp.software-eng Subject: Re: use of metrics Message-ID: <35346@mimsy.umd.edu> Date: 7 Jun 91 02:33:16 GMT References: <795@tivoli.UUCP> <35121@mimsy.umd.edu> <4794.284cfad3@iccgcc.decnet.ab.com> Sender: news@mimsy.umd.edu Distribution: na Organization: University of Maryland Dept of Computer Science Lines: 72 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. >>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, meets expectations, produces work that doesn't need to be redone, etc. And they talk to their tech people who, in my limited experience, seem to know each other's work pretty well. >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. 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 collecting human-intensive data, this is vital. Say that we care deeply about the amount of computer resources spent on project X. But say much of project X work is done on PCs, where automated collection is basically impossible. Then the metrics program relies on the employees to make accurate reports. Say the reports are way off on the low side. When planning the next project, the planner sees that not much machine time was used previously, and decides that not many machines are necessary. A situation such as this seems like it would lead to failure, or at least some interesting recantings of earlier results. And such a failure is exactly what the metrics program could have prevented with ease! 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! 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 ;-) chris... -- Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu /\ 4122 AV Williams Bldg 301 405-2721