Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!iggy.GW.Vitalink.COM!pacbell.com!att!att!cbnewsm!lfd From: lfd@cbnewsm.att.com (Lee Derbenwick) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Summary: metrics not _necessarily_ bogus, but some are Message-ID: <1991Apr4.224939.20793@cbnewsm.att.com> Date: 4 Apr 91 22:49:39 GMT References: <9233@castle.ed.ac.uk> <1991Mar25.164133.29674@unislc.uucp> Organization: AT&T Bell Laboratories Lines: 46 In article , jgautier@vangogh.ads.com (Jorge Gautier) writes: > In article <1991Mar25.164133.29674@unislc.uucp> klb@unislc.uucp (Keith L. Breinholt) writes: [ ... ] > > Now if a supposed professional comes to me and tells me that they > > don't want to be measured (i.e. they don't want to improve). I have > > real doubts about the future of that individual. > > I don't mean to sound negative about this, but your i.e. is bullshit. > The people who don't want to change are the ones who don't want to > improve. Measurement has nothing to do with it. Some people don't > want to be measured because they know that the metrics being used are > bogus. If a supposed manager comes to me and tells me that they want > to "measure the software development process," I have real doubts > about the past and future of that individual. A metric isn't necessarily bogus, though I suspect that any _single_ metric of the software process, in isolation, omits vastly more than it measures. And all the numerical metrics we've got, put together, still omit a significant amount of what you'd _like_ to measure. So our best metrics, combined, still can't describe the whole process. But I don't fault people for wanting to measure the software process, as long as they know that they can only measure _some aspects of some pieces_. On the other hand, sometimes _truly_ bogus metrics get introduced... My candidate for truly-bogus-productivity-metric, one that I've actually seen used (briefly): number of program changes ("PC"s) per staff-year. In an environment where there is a large body of existing code being maintained and enhanced with new features, it is superficially plausible that the more program changes, the more old bugs and new features are being dealt with. Unfortunately, the easiest way to be a "productive" developer by that metric is to code sloppily, skip unit testing, and let the system test group find your bugs for you. Each bug they find has to be fixed and PCed, so you up your PC count with minimal effort. (And avoid unit testing, besides!) Bogus metrics like this one, rewarding the _opposite_ of desired behavior, are among the worst. And if I "don't desire to be measured" according to them, it is _not_ because I don't wish to improve. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd