Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!abvax!iccgcc!kambic From: kambic@iccgcc.decnet.ab.com Newsgroups: comp.software-eng Subject: Re: Software Quality Message-ID: <3955.27ee3172@iccgcc.decnet.ab.com> Date: 25 Mar 91 22:20:50 GMT References: <36650001@hpopd.pwd.hp.com> Lines: 25 In article <36650001@hpopd.pwd.hp.com>, daves@hpopd.pwd.hp.com (Dave Straker) writes: [...SLIGHTLY EDITED...] >> their methods. To attach metrics to this fundamental activity of >> process quality improvement--"let's see, last month THE CODE WAS 7.2 on our >> quality index, this month THE CODE 8.1: good CODE!"--is ... well, I >> don't have the words to describe it. Of course, there are those who > > "Process data must not be used to compare projects or individuals. Its > purpose is to illuminate the product being developed and to provide an > informed basis for improving the process. When such data is used by > management to evaluate individuals or teams, the reliability of the > data itself will deteriorate." > > --- Watts Humphrey, "Managing the Software Process", Addison Wesley 1989 No question about the statement. Now, even with all of the good words, how do we get Humphrey's principle into a useful paradigm. If x produces buggy code from month to month to month, does management let it continue or do they get this person into a bug reducing class. Or do they continue to rework the code because the "data must not be used.." to evaluate x. Tough problem. This may be taking the problem to an extreme but if data indicates that the problem may be in a person's techniques or style, what do you do if you are management or a member of a team? GXKambic standard disclaimer