Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!rtech!linda
From: linda@rtech.rtech.com (Linda Mundy)
Newsgroups: comp.software-eng
Subject: Re: Software QUALITY Engineering
Message-ID: <3806@rtech.rtech.com>
Date: 11 Oct 89 22:02:51 GMT
References: <135@quame.UUCP> <4331@ae.sei.cmu.edu>
Reply-To: linda@rtech.UUCP (Linda Mundy)
Organization: Relational Technology Inc, Alameda CA
Lines: 107

In article <4331@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>In article <135@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes:
>
>>The scary thought is that the Japanese are beginning to use this philosophy
>>to work with software (philosophy -> Deming philosophy).
>>If all follows, they will have perfected the software development process,
>>and produce higher quality software (error free), faster and cheaper.
>
>I have to disagree here -- error free does not equate to quality.  The best
>process in the world can not turn a poor design into a good one; all it can
>do is produce faithful copies of the design.
>
I have some problems with your response.

First, while "error free" is not the whole story of software quality, it's
certainly a key element, not to be waved away lightly.

Second, you imply that improving the software development process somehow means
ignoring design issues, while also managing to imply that neither the Japanese
nor Deming's system deal with those issues.  I find this attitude both smug and
naive.  In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought
indeed that the Japanese will proceed with improvements in the software process,
while our own engineers sneer at "process" and believe that they can produce
quality software while ignoring process.

In fact, process can affect design in a very positive way.  For example, the
process can ensure that marketing, sales, testing, and technical support people
(to name but a few) are involved in initial high-level design, and in later
(possibly lower-level) design reviews.  This could have impact on:  the
usability of the interface, the actual features included in the product, the
organization of the code, how it is shipped (what media, what is the
organization of files, what is the installation procedure, etc.), and on
whether it truly meets customer needs (marketing, sales and tech support are
often in a better position to judge customer needs than are development
engineers -- note I said "often", not always).

And of course, to reiterate the original poster's point, process can certainly
help to minimize errors in the code.  Good code management procedures can make
bug fixes visible (serving an educational purpose, helping people to avoid the
same kinds of mistakes); it can help to ensure that old bugs don't creep back
into the code, etc.

In other words, process, at whatever level you chooose to define it, can have
a major impact on software quality.  Good theory, good algorithm design, good
coding style -- all of these are necessary, but most certainly not sufficient
to produce a quality product.
>
>>I would hope that we catch on and begin to perfect the design process,
>>get it under control, and produce higher quality software. (No vaporware,
>>and no errors.)
>
>Again, the implication is that production process control has something to
>do with the design process -- they are separate!
>
Wrong.  And especially in the arena of software!  But don't take my word for
it, allow me to quote Tom Peters from his latest book _Thriving on Chaos_:

	(discusses the flexibility of Japanese motorcycle companies, their
	ability to quickly introduce new models and to perfect the production
	process):  "This requisite increased flexibility is possible only
	because of much tighter linkages among design, engineering, and
	manufacturing in Japan than in the United States.  (This trait, also
	taught to the Japanese by American W. Edwards Deming,...etc.)"

and later in the same book:

	"Thus, in the first place, the Japanese treat every product as an
	ongoing experiment and are constantly engaged in improving it.
	Second, the typical Japanese firm's close integration of design,
	engineering, and manufacturing induces constant experimentation..."

and later:

	(discussing the success of Ford's Team Taurus effort):  "With Taurus
	... we brought all disciplines together ... The manufacturing people
	worked right with the design people, engineering people, sales and
	purchasing, legal, service and marketing."  

Note that while the above discussions mention flexibility, the whole point is
*better quality, as perceived by the customer*.  The flexibility allows the
necessary responsiveness to customers, so that those other quality issues --
like, are these features useful to actual paying customers -- can be
addressed effectively.

>
>>Please feel free to comment on this topic!!
>
>Gee, thanks, but you knew we would feel free without the invitation!
>
>>P.S.  I refuse to use the term BUG -- it makes it sound as if it is not
>>the fault of the software developer... it is an error... it is WRONG!!!
>
>Excellent sentiment -- I agree!
>
>
>Rich
>-- 
>It is not the possible that determines what to hope for --   
>it is hope that determines what is possible.
>Richard J. Oman                                               rsd@sei.cmu.edu
>-----------------------------------------------------------------------------


-- 
"Who are you to tell me to question authority?"

Linda Mundy	{ucbvax,decvax}!mtxinu!rtech!linda