Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!uunet!weyrich!orville
From: orville@weyrich.UUCP (Orville R. Weyrich)
Newsgroups: comp.software-eng
Subject: Re: industrial engineering and metrics (was Re: bridge building and discipline)
Message-ID: <1991May16.151913.13770@weyrich.UUCP>
Date: 16 May 91 15:19:13 GMT
References: <1991May14.150350.2837@den.mmc.com> <1991May15.180943.6796@netcom.COM> <1991May15.223135.12381@m.cs.uiuc.edu>
Reply-To: orville@weyrich.UUCP (Orville R. Weyrich)
Organization: Weyrich Computer Consulting
Lines: 87

In article <1991May15.223135.12381@m.cs.uiuc.edu> marick@m.cs.uiuc.edu (Brian Marick) writes:
>jls@netcom.COM (Jim Showalter) writes:
>
>>I find it odd that metrics have been
>>successfully used in just about all other industries to improve quality,
>>reduce risk, identify incipient problems, increase productivity, etc, but
>
>Let's be careful.  For example, consider industrial engineering, where
>people used to measure "cost of quality".  The cost of quality was
>calculated by adding together two curves.  The first curve was the
>cost of shipping bad product, which decreases with increasing
>inspection.  The second is the cost of inspection itself, which
>obviously increases.  Businesses strived to position themselves at the
>minimum, the "acceptable quality level".
>
>This turns out to be a bad idea.  The root problem is that it's very
>hard to measure the true cost of shipping bad product.  For example,
>how do you measure low-level annoyance with rattling parts --
>something that doesn't result in a warrantee charge, but may mean the
>customer buys another brand next time?  This incomplete data then led
>directly to mistaken strategies.
>
>The modern approach, following Taguchi, Deming, and company, has (in
>principle) abandoned a measurement (cost of quality) and replaced it
>with a system of faith that asserts that increased quality is *always*
>cost-effective.  In this case, the faith has worked better than the
>metric.

This principle can't be useful when carried to an extreme -- a cost/benefit
analysis must be done. Consider for example an automotive part which is
presently machined to a tolerance of 0.01 mm. Perhaps decreasing the
tolerance to 0.005 mm will give a noticeably higher quality product at a
reasonable cost. It does not follow that it is therefore desirable to
obtain more sophisticated [expensive] equipment in order to reduce the
tolerance to 0.0001 mm. There IS a law of diminishing returns, and a 
successful company must have a reasonably good grasp of where these 
break-even points are.

As someone else in the group has pointed out, blindly adding additional
steel and concrete to a bridge is in most cases counterproductive.
I would suggest that the same is true of blindly adding quality.

If you can't measure something, you can't control it or set priorities.
I conclude that effective metrics are essential to improvements in software
quality. HOWEVER ... see below.

>
>I'd guess that a sizable percentage of the anti-metric camp is
>justifiably fearful of the effects of measuring (and, inevitably,
>concentrating on) the inessentials.  Another sizable percentage is
>spoiled rotten.

There is a real problem with the Hiesenberg uncertainty principle 
when using metrics [that is, the act of measuring the system upsets the
system]. As an example, consider simple metrics programs which were
developed a few years back to "grade" the "style" of student programs.

To take one specific aspect, long identifier names were considered to be
better style than short ones. So what happens when the students start
running their programs through the style grader? They find that long 
identifier names improve their scores, and so they increase the number of
characters in the identifier names. They don't improve the semantic content
of the identifier names, just make them longer. The program has hot really
gotten better, it is just scored as being better. And some could argue that
long, meaningless names are worse than short meaningless names.

>
>Disclaimer:  I'm not an industrial engineer.  What I know, I know from
>taking industrial engineering courses, reading, and being an employee
>of a company that's been quite successfully fanatical about quality.
>
>Brian Marick
>Motorola @ University of Illinois

Is Motorola's current position on drug testing an aspect of their
being fanatical? :-) It seems that impairment testing [which they do not do]
would be more effective in improving quality. See the recent discussion
in misc.jobs.misc.



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************