NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/software/4327

Text File | 1992-11-17 | 5.5 KB | 117 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!pioneer.arc.nasa.gov!lamaster
From: [e-mail] (Hugh LaMaster)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: NASA Ames Research Center, Moffett Field, CA
References: <[e-mail]> <[e-mail]> <georgerj.721551764@emerald> <[e-mail]>
Date: Mon, 16 Nov 1992 21:20:36 GMT
Lines: 105

In article <[e-mail]>, [e-mail] (Cameron Laird) writes:
|> In article <georgerj.721551764@emerald> [e-mail] (Richard J. George) writes:
|> >[e-mail] (Cameron Laird) writes:
|>             .
|>             .
|>             .
|> >>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.
|> >
|> >I disagree with the assumption that the role of the software engineer
|> >will be de-skilled in years to come.  From looking at tools which are
|> >available now (ilogix for example), I see the skill moving further
|> >up the lifecycle.  More pride will be placed in getting a complete
|> >set of requirements, and producing a design that satisfies those
|> >requirements.
|> >
|> >Coding itself is (should be) cranking the handle.  It is the bricks
|> >and mortar of the architect - and how many bridge building engineers
|> >get their hands dirty?
|>             .
|>             .
|>             .
|> We're in agreement.

I don't know whether Richard J. George agrees, but I don't.

First, I don't see how someone who can "show facility at
combining standard components, at translating
high-level specifications into solutions, and at
carrying out their business within a *measured*
workplace." can possibly be described as "de-skilled" compared
to someone who "codes".  In fact, just the opposite.

Second, in the case of the analogy with the automobile
industry, if you consider the percentage of the U.S. population
who worked in highly skilled automotive industry jobs in
1910, say, and compared it to later, post-Henry Ford years,
there is surely a *vast* increase in the number of people
working at all skill levels and job types.  And many fewer,
of course, in the "horse industry".  Did Henry Ford
"de-skill" society?  Perhaps.  Perhaps it takes more skill
to raise horses and drive carriages than to be an assembly
line worker.  On the other hand, it is a very tough
comparison to make, because you have to consider job categories
which comprise roughly 10% of the economy, and the change
went across a very large number of job categories.

For example, I have argued previously that software has very
little "assembly" phase compared to mass-production style
manufacturing.  This might mean that there will be very few
entry-level and unskilled jobs.  It might be, however, that
the unskilled jobs will be elsewhere, in keeping databases
up to date, in sales, etc.  Until you know, you don't know.


                       One of the points I've been
|> trying to make is that moving "the skill ... up
|> the lifecycle" *is* what many of our colleagues
|> see as "de-skilling".  There's ample historical
|> precedent for this identification--for a variety
|> of socio-cultural reasons, manufacture of fire-
|> arms, automobiles, textiles, and merchant ships
|> all went through the same struggle, with the same
|> confused and confusing debates.
|> --

One of the points of debate which keeps coming up is the word
"measured", which you emphasized above.  My question, and
not a rhetorical one either, I emphasize, is this:

What have "they" measured in other engineering disciplines?

What does Ford, or, even better, Mazda, measure inside the
*engineering* part of the organization which helps them determine that
they can afford to do all the engineering development on a particular
car model?  Take Mazda with the Miata, say.  How did they know they
could afford to do all the engineering on it, when they were only planning
to sell a small fraction (1/5?) the unit volume that a typical
mass-produced car costs?  Do they actually measure engineering
productivity, and if so, how do they do it?

The only articles on Japanese engineering that I have read show an
accelerated engineering schedule compared to U.S. companies, but no
numbers, measurements, or anything else.  Instead, they describe
engineering *processes* that the companies use to get a better match
between requirements and products.  These processes seem to be very
labor intensive, but unmeasured.  In fact, they seem to be very
similar to the kinds of requirements analyses which people in software
have been doing for a long time.  (But not, I guess, people in the
auto industry ...)  In some cases, some of the methods for analyzing
requirements (e.g. QFD) seem to be more quantitative with respect to the
*requirements*, but not the length of time necessary to actually do
the requirements analysis.  Please correct me if I am wrong.


--
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  [e-mail]
  Moffett Field, CA 94035-1000  Or:        [e-mail]
  Phone:  [phone]                     #include <usenet/std_disclaimer.h>