From: claird@litwin.com (Cameron Laird)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Organization: Litwin Process Automation
Date: Mon, 9 Nov 1992 15:34:29 GMT

lamaster@george.arc.nasa.gov (Hugh LaMaster -- RCS) writes:

>In article <1992Oct26.195131.29756@litwin.com>, claird@litwin.com (Cameron Laird) writes:
>|> lamaster@george.arc.nasa.gov (Hugh LaMaster -- RCS) writes:
>|> 
>|> >In article <1992Oct19.094707.9256@netcom.com>, mcgregor@netcom.com (Scott Mcgregor) writes:
>|> 			.
>|> 			.
>|> 			.
>|> Mr. LaMaster makes his points well, but I
>|> don't agree.  The marketplace will be won
>|> by organizations that are able to deliver
>|> products that show more manufacturing and
>|> less design--at least, that's what I assert.

>But, unfortunately, since the manufacture component in software is 
>practically nil, you don't have that choice.  The only way to lower 
>the cost and improve the quality of software is through better design.
>That is what I assert.
Good; we're focussing here on some issues where
there is real disagreement.  I'll explain a bit
more of what I have in mind.

Successful software organizations of the year
2000, in my estimation, will not be those that
regard applications problems as solved by "coding
up a program"--the tradition in which most of us
grew up--or even by design, in its lower-level
senses.  They will, as one contributor recently
complained, have a "de-skilling" attitude.  They
will expect their employees to show facility at
combining standard components, at translating
high-level specifications into solutions, and at
carrying out their business within a *measured*
workplace.

In the early days of the automobile industry,
engineers spent some portion of their time think-
ing about the pitches of machine screws, the
thickness of wood panels, and so on (at least,
this is so according to the anecdotes that have
come my way.  I recognize that I ought to re-
search this more).  Eventually it was realized
that these searches for efficiency were distrac-
tions; engineers' and technicians' time were
better spent combining standard components in
relatively standard ways, to produce evolutionary
(*not* revolutionary)tionary) improvements.

There will always be a place for the revoluti-
onaries.  Moreover, I know it will be disturbing
for many of us now reading comp.software-eng to
accomodate ourselves to the industrial practices
that are headed our way.  The winners of the near
future will *force* there to be a choice between
design and manufacture, in favor of the latter;
they will arrange their organization and processes
to take more and more advantage of automation.
			.
			.
			.
>I'm not arguing for complacency.  I am arguing that we are up against a 
>subtle problem when we talk about software quality.  Because measuring 
>software quality implies measuring design quality, manufacturing-oriented 
>statistical quality approaches are not good enough, and will lead us astray.  
Certainly they are subtle--but the world will
be won by those who don't let subtlety inter-
fere with their intensity.  Organizations will
acquire habits of measuring what is relatively
easy to measure, and that will suffice.

In what followed, you make a number of other
interesting points.  I look forward to following
up on them, although not in this article, which
already has grown too long.  For my sake, I hope
you're right, and I'm wrong, because my experi-
ence will put me at a relative disadvantage in
the world I anticipate.
			.
			.
			.

-- 
Cameron Laird		+1 713 996 8546

claird@litwin.com
claird@Neosoft.com
Newsgroups: comp.software-eng