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

Internet Message Format | 1992-11-18 | 8.0 KB

Path: sparky!uunet!ogicse!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!csus.edu!netcom.com!mcgregor
From: [e-mail] (Scott Mcgregor)
Newsgroups: comp.software-eng
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Message-ID: <[e-mail]>
Date: 19 Nov 92 02:38:34 GMT
Article-I.D.: netcom.1992Nov19.023834.27234
References: <georgerj.721551764@emerald> <[e-mail]> <[e-mail]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Lines: 163

In article <[e-mail]> [e-mail] (Hugh LaMaster) writes:

>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.


A person becomes de-skilled when the skills that they have developed
over many years of on the job experience no longer need to be done
because there are automated ways to do it that no longer require a
skilled operator.  The fact that the operator is now freed to be
re-trained with new more intellectually demanding skills, may be good
for society (I believe it is in the long run), but can be  a definate
short term economic hardship on the person whose existing expertise is
no longer needed.  In the long run, if the person is successfully
retrained they may become better off. However, for a while someone
with years of (the no longer needed) work experience finds themselves
on par with fresh new job entrants.  This can be bad for the
self-esteem. Meanwhile they probably have expenses (e.g. mortgages)
typical of someone with lots of experience and a high skill level.
The problem faced by managers is dealing with the long term larger
economic forces and their need to be humane with regards to the short
term economic dislocations that are implied.

>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.

See "The Machine That Changed the World" (subtitled "The story of Lean
Production How Japan's secret weapon in the global auto wars will
revolutionize wester industry") by James P Womack, Daniel T Jones and
Daniel Roos of the MIT International Motor Vehichle Program, published
by Harper Perrenial 1990.  You'll find in it and in its exhaustive
references much of the measurement information you want.  Truthfully,
the Japanese don't have a monopoly on this, but they seem to do more
about the information they collect on average than do US or Europeans
on average.

Auto companies DO have considerable information about how long it
takes to design, namely their historical information and wage sheets.
There are large variances from model to model--but it is possible to
make economic decisions nonetheless.  An auto manufacturer may choose
to back a project in which they will STILL make money, even if the
project takes 50% longer than expected (e.g. 7.5 years instead of 5),
and even if it sells only 50% of what was expected.  But they know
they will make a lot more if they can do it as expected or faster, and
and generate the expected demand or more. Auto manufactureres
typically don't invest only in projects that will make a profit only
if everything goes as expected.

Sometimes I am not so sure about software companies.  They sometimes
seem to put resources on projects that will only make money if they
meet a tight market window and have high initial demand.  They might
be better off skipping those projects and working on some less
demanding ones occassionally.

In most other industries estimates are common, budgets are built based
upon not merely the mean estimate, but allowance for significant
uncertainty. Padding we call it in software.  Ballpark estimates,
safety factors, etc. are all understood to be imperfect and yet quite
satisfactory for making operating decisions.  Many software developers
and managers are not comfortable with this lack of precision.  They
prefer pure mathematics where the answer to 2+2=5 is "wrong" and not
"close enough". They decline to give any estimate, rather than choose
one and have a variance when the actual is measured. This reluctance
to deal with anything that isn't purely deterministic and calculable
makes the software industry different from many others.

Ironically, I think that even the reluctant software developers can
learn to estimate as accurately as say civil engineers do.  The
following previous conversations are illustrative:

With a civil engineer: "How long to build a bridge like that?"

"Oh let's see, there's a guy standing next to the bridge there, let's
assume he's about 5 feet for easy arithmetic. if he laid down he'd
extend about half way between those two struts so they'd be about 10
feet apart. Theres one, two, three---ten of them. So the bridge is
about 100 feet long, with ten major struts, based on past experience
maybe 6-18 months to design and build."

With a software engineer: "How long witll it take to build the program
in this spec?"

"I don't know. I couldn't say"

"You haven't any clue at all? How about an estimate?"

"No, I really couldn't tell you."

"You mean it might be done in a day?"

"No, no way, too complex."

"How about a week?"

"No definately more difficult than that."

"A month?"

"Well, probably not. No definately not."

"A year?"

"No that's probably too long.  Well maybe if things go very badly."

"So it will probably take between a month and a year?"

"Yes, definately. But I can't tell you when exactly."

"So you just gave me an estimate. If I can make sure we can make a
profit, even if the project runs a year, then I can be sure that this
is a good thing to do.  If it is only profitable if it takes less than
a year I'm taking a bigger risk, right?"

"Sure.  But that's a pretty big variance. You don't really know how
long it is really going to ta."

"I don't need more accuracy.  I just need to know the possible
variances, not just the mean. As long as you are within those, no
matter how big they are, I can manage the risk and project go/no go
decisions. I can manage risk/reward (profit requirements).  But if you
don't give me any estimate I am hosed."

"Oh, well that's not too hard then."

"That's what I thought all along!"

(The above are based on real conversations I have had, greatly
synopsized. I don't mean them to be representative of ALL software
engineers and managers, or even necessarilly most, but they seem to me
representative of a significant enough number of people to account for
some of the differences we see in software management. And consultants
like myself can and do work with people who have these problems to
achieve dramatically improved predictability and profitability.  None
of this is new potential we added, we just use the knowledge the
people doing the work had--but had never expressed before.  (Of course
if it was easy for all organizations to discover this information on
their own they wouldn't need consultants to act as midwifes.  Luckily
they can learn from the process and do it themselves next time!)




--

Scott L. McGregor        [e-mail]
President            tel: [phone]
Prescient Software, Inc.    fax: [phone]
3494 Yuba Avenue
San Jose, CA 95117-2967