NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/software/4203

Text File | 1992-11-09 | 3.9 KB | 98 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!dynsim1!claird
From: [e-mail] (Cameron Laird)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Message-ID: <[e-mail]>
Organization: Litwin Process Automation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 9 Nov 1992 15:34:29 GMT
Lines: 87

[e-mail] (Hugh LaMaster -- RCS) writes:

>In article <[e-mail]>, [e-mail] (Cameron Laird) writes:
>|> [e-mail] (Hugh LaMaster -- RCS) writes:
>|>
>|> >In article <[e-mail]>, [e-mail] (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        [phone]

[e-mail]
[e-mail]