Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!defun.utah.edu!shebs
From: shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs)
Newsgroups: comp.software-eng
Subject: Re: A Cynic's Guide, part 1
Message-ID: <5313@utah-cs.UUCP>
Date: 4 Mar 88 15:36:35 GMT
References: <2541@Shasta.STANFORD.EDU>
Sender: news@utah-cs.UUCP
Reply-To: shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs)
Distribution: na
Organization: PASS Research Group
Lines: 84

In article <2541@Shasta.STANFORD.EDU> neff@Shasta.UUCP (Randall Neff) writes:

>Why the big difference?   Both hardware and software are working instantiations
>of behavior as described by requirements and specifications.  There is the
>obvious difference in the scale of the projects:  designing and implementing
>a RISC chip is a lot simpler than designing and implementing a compiler for
>it or (gasp) a new operating system for it.  Why can hardware engineers do 
>their job so well and software engineers talk about the (huge) percentage 
>lifecycle cost in the maintenance phase?   

You've answered your own question, at least partly.  Software complexity
is perenially underestimated.  A large piece of software is closer to a
space shuttle or nuclear power plant in the complexity of its behavior.
To some extent, this is due to the "nonlinear" nature of software behavior
that someone has mentioned.  Unlike circuits, software doesn't degrade at
a known rate - failure will be unexpected and catastrophic.

>Looking at the last ten years in hardware design tools, the following trends
>can be observed:
>
>-- Willingness to learn new paradigms of design, new methods, new tools.
>   Hierarchical design in functional languages, logic, switches, transistors.
>   Willingness to change methods and design in order to use tools.

Amen.  Try arguing with a rabid assembly-language or C programmer, to see
just how bad it is in software.  Higher-level languages are met with large
amounts of skepticism and indifference.  To be fair, both programmers and
managers are guilty here.

>-- Capital investment in both hardware (originally $75,000 to $100,000 per 
>   station) and in software (like $100,000 programs).   Buy or lease Cray time.
>   Use days of mini and super-mini computer time to check design.

I would *love* to have the luxury of extensive testing in controlled
environments.  The word "luxury" describes the current situation.  Guilty
parties are everybody, including the customer who buys software known to
be incompletely tested, because "I've just got to have it now!".

>-- Return on Investment (ROI) and productivity gain was obvious (sometimes
>   order of magnitude) over previous methods.  

This is more of a problem.  Claims of gain in software productivity have
been regarded with considerable suspicion, perhaps because of the lack of
repeatibility?

>-- Manufacturing cost was increased to drastically shorten design time with 
>   standard cells, gate arrays, and silicon compilers.
>-- Enormous amounts of reuse of specification, design, and testing through
>   standardized part libraries:  off shelf parts, standard cells, gate array 
>   cells, etc.
>-- Constructing the test procedures along with the design; and designing for
>   easier testing.

All three of these approaches in the software realm fall victim to the same
concern: efficiency.  This is partly a legacy of the 50s, when the self-taught
programmers of the time were willing to do *anything* to squeeze out a few
more cycles or a few words of memory.  It was OK to violate any abstraction
or to use any quirk of the system.  Even secret changes to the specifications
were acceptable (assuming that specs were used at all).  That has changed some-
what, but programmers are still caught in the tug-of-war between reliability
and performance.  When was the last time you heard a customer said of a piece
of code "yeah, this is fast enough"?

>Why haven't software engineers followed similar trends?

Any half-trained software engineer knows how things *should* be done.
Formal specifications, reuse/standardization of components, extensive
testing and test generation, and so forth.  The time necessary to do all
this is much larger than the average time allotted to software efforts,
and between management and customer, the time gets shrunk to something
that fits other schedules.  In the case of software publishing, there is
the incentive of competition to shrink the schedule.  Then the objecting
software engineer's competence is impugned, and he/she imprudently claims
"I can do all that in three days" (images of the legendary "real programmer"
in the back of the head).  All downhill from there...

The solution?  Software engineers have to stand up for what they know is
right, undisciplined hackers have to be retrained or fired, managers have
to be knowledgeable about what is and isn't possible, and customers have
to be both more patient, and completely unforgiving of mistakes in delivered
software.  Nothing technical here; as Fred Brooks said, "no silver bullet".

							stan shebs
							shebs@cs.utah.edu