Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.software-eng Subject: Re: Metrics Example Message-ID: <1991May24.201741.14138@netcom.COM> Date: 24 May 91 20:17:41 GMT References: <24600@unix.SRI.COM> <1991May23.231339.22418@netcom.COM> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 60 >The point that worries me is this assertion that the metrics are ``real >measures''. [I'm happy to believe that they are; it's just that I think they >need justification. As earlier posts of mine have said, just because they're >*numbers* doesn't make them *meaningful*.] We are veering off into semantics and the philosophy of causality. Define what you mean by "meaningful". In a previous post I pointed out that if rutabaga consumption per developer could be shown to be a good predictor of project success, then it was a valid metric with which to make such predictions. The counterargument is absurd: "Yeah, there's a 100% correlation, but we won't use that metric anyway because it's SILLY.". >Are these ``real measures''? A priori, they seem as real as (say) defect >density, or uncommented-lines-of-source-code, or compiles-needed-before-no- >syntax errors. If they can be shown to have a correlation with project success, then, yes, they ARE real measures. What else would you call them? >In any case, one of the points of the original poster was that >you could shotgun the team with a variety of metrics and keep those that >``worked'' (whatever that means). What "worked" means is that you can demonstrate from historical data that Metric #7 is an accurate predictor of project success. >If we don't understand why they work (for example, suppose that aerobic hours >turned out to be a good predictor for project success), then we should say so. >If their effectiveness has be determinded by purely empirical means (ie, we >have no underlying theory), we should say so. What we should *not* do is call >metrics ``real measures'' without pointing to a justification. Smoking is a great predictive metric for lung cancer, even though the precise mechanisms for the entire chain of events leading to the cancer have yet to be fully elucidated. Would you reject smoking as an indicator of lung cancer because you haven't yet proven causality? This is the tack taken by the cancer lobby, but who wants to be on their team? Lack of dietary fiber is a good predictor of colon cancer, and yet they are much further from having a precise explanation of the mechanisms whereby eating nothing but Ho-hos ruin one's bowels. Would you then decide to eat nothing but Ho-hos, just because the precise mechanism is not yet explained? >But I think we must be clear as to >*why* we thing metrics are ``real'' and *why* we think they work; We think they're real because project in trouble tend not to have any metrics, and projects on schedule tend to use metrics. As for WHY we think they work, this is just the causality issue again--I'm personally not particularly concerned with why the metrics work: I'm concerned with them working, and that's about it. Let me make my position clear: I'd practice VOODOO if someone could provide me with evidence that projects using it are more successful than projects not using it. And I would do this without spending ten seconds trying to figure out WHY it worked. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *