Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ftpbox!motsrd!motcid!saxena
From: saxena@motcid.UUCP (Garurank P. Saxena)
Newsgroups: comp.software-eng
Subject: Re: Software Quality
Keywords: Quality, Metrics, Process Improvement Team, TQM
Message-ID: <4909@berry7.UUCP>
Date: 3 Apr 91 16:05:13 GMT
References: <36650001@hpopd.pwd.hp.com> <3955.27ee3172@iccgcc.decnet.ab.com> <1853@manta.NOSC.MIL> <1991Apr2.200958.8208@spool.cs.wisc.edu>
Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL
Lines: 62

dparter@shorty.cs.wisc.edu (David Parter) writes:

>>In article <36650001@hpopd.pwd.hp.com>, daves@hpopd.pwd.hp.com (Dave Straker) writes:
>> 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?

>If a specific member of the team is producing buggy code from month to
>month, that is, the quality of his or her work is siginificantly worse
>than that of the rest of the team, the other members of the team,
>probably including management, already know this. 

The issue raised by Dave Straker is germane to the area of metrics and
measurements in general. More so, because managers of software engineers
have very little objective data on which to  base their evaluation of these 
engineers. Thus, as soon as they get these metrics, they will start 
using them to evaluate the person's abilities. So far so good. However, if 
the manager takes positive steps and tries to improve the person's 
capabilities, that is a good use of the metrics data. What engineers
fear most is that the metrics will be utilised in a manner which will 
affect them negatively. 
From my own previous experience, when we were writing the Software Requirement 
Specifications for a new product, we decided to measure the number of 
changes made per draft version of the Specifications document. 
This measure was put in the Revision History page of the 
Specification document itself. The idea behind this was to have 
some measure of changes occuring in this document over time. 

All the team members agreed that this was a good idea. However, 
when the time came to issue the Specifications document to the 
world (which included the upper management), all the
engineers screamed and shouted about removing the numbers from the
Revision History page of the document, as it would reflect on the
quality of the people working on this document. The final decision
was to leave the numbers in, but not explain what they meant!

As Humphrey says in a recent paper ("Predicting (Individual)
Software Productivity", IEEE Transactions on S/W Engg, Feb. 1991),
"In estimating the productivity of software individuals and groups,
it is important to have an objective method for utilizing 
available data. Without such a basis, it is hard to guard against the 
pressure to use productivity values that give the most desirable
business results."

As a colleague of mine puts it, the ideal way to use metrics is
akin to the confessional box in church. You report your metrics,
without being identified and they are never to be used against
you and all is forgiven.

------------------------------------------------------------------
Garurank P Saxena		"when the fight begins within
CASE Development Group 		  himself, then a man's worth
Motorola Inc			  something".
Arlington Heights, Illinois	Phone: (708) - 632 - 4757
				Fax:   (708) - 632 - 4430
------------------------------------------------------------------