Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tada
From: tada@athena.mit.edu (Michael J Zehr)
Newsgroups: comp.software-eng
Subject: Re: Designing to specs
Summary: programs vs. bridges
Message-ID: <15232@bloom-beacon.MIT.EDU>
Date: 19 Oct 89 15:25:19 GMT
References: <89291.134836UH2@PSUVM.BITNET>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tada@athena.mit.edu (Michael J Zehr)
Organization: Massachusetts Institute of Technology
Lines: 40

In article <89291.134836UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes:
>I thought of another wrinkle on the question of the difference between
>the "design" of software and the "engineering" of other stuff.  
>[legal controls like max people per building or max vehicle weight per
>bridge, etc.]
 
There's another difference i've thought of.  "Real" structures are much
less likely to be used for a purpose other than intended.  on the
humorous side, bridges are very rarely picked up and moved somewhere
else to be used for a different reason.  :-)  

(there are of course times when buildings are renovated, but that often
costs close to (or more!) than the cost of building it in the first
place, so it's treated as a serious project.  too often software is
supposed to be reused and it's expected to take no time to tailor
something for a different environment.)

here's a concrete example of something i found in a production system i
was maintaining once upon a time: there was a sort procedure which was
copied (almost) verbatim from K&R (or so a comment said -- i didn't
check it for accuracy) that was o(n^2) in time-execution and was being
used to sort arrays that were 7000 elements long.  i told someone to
replace all calls to it with a call to a library sort routine,
drastically speeding up all the operations which required that sort.

there was a mistake here in taking a "toy" sorting program that was
designed for maybe 50 elements and scaling it up by a factor of 100.
and that mistake shouldn't be overlooked... but such mistakes are made
because they're *possible* in software-enginerring.  you simply can't
arbitrarily copy something and scale it to whatever size you want in
"hard" engineering disciplines.

and though it's this characteristic of software-enginerring which allows
for major mistakes, it also allows for major successes.  (can you
imagine a contractor saying "well, we built a similar
highway/bridge/bypass system for another city, so we can do one for you
in 1/10 the time and 1/4 the cost." ???  this is the sort of thing that
can be done and is being done in software-enginerring today.)

-michael j zehr