Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ncar.ucar.EDU!ftower From: ftower@ncar.ucar.EDU (Francis Tower) Newsgroups: comp.software-eng Subject: Re: Metrics Example Message-ID: <11560@ncar.ucar.edu> Date: 27 May 91 14:02:43 GMT References: <24600@unix.SRI.COM> <1991May23.231339.22418@netcom.COM> <1991May24.201741.14138@netcom.COM> <1991May25.171824.22845@visix.com> Sender: news@ncar.ucar.edu Reply-To: ftower@ncar.ucar.EDU (Francis Tower) Organization: Climate and Global Dynamics Division, NCAR Lines: 28 Supportive managerial involvement is vital but as a project becomes really huge the managerial span of control places some managers out of direct contact with the worker bees. Then metrics appear because they give a quantitive (if not inaccurate) feel for the project. The key point in my experience is that upper management will almost always demand to see metrics. Since humans have a tendency to avoid looking bad on these metrics, programming professionals will'Game' their approach to the metrics. The best move my firm made was when the new CEO decided that each division would create a list of what was really important to measure based on their unique mission and their customers. The parent division approved the division lists, the divisions were expected to implement their chosen metrics, BUT! the divisions were not to report any numbers to the parent or to other divisions. Programmers still 'Gamed' the metrics but the gaming was in a direction which promoted better software design and development. Such changes were of course fought expecially by management which didn't like change or the sense of loss of touch. How could their compare one division against another was their lament. The Boss's answer was you cann't. Symptomatic Relief? Our chief scientiest kept cranking parameters until a given piece of code finally gave reasonable results. Later, the error in the code was found which negated the heroic fiddling.