Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <10185@as0c.sei.cmu.edu>
Date: 23 Jan 91 15:34:59 GMT
References: <10061@as0c.sei.cmu.edu>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 69

In article <10061@as0c.sei.cmu.edu> Bruce Benson writes:

>In article <10060@as0c.sei.cmu.edu> Richard S D'Ippolito writes:
>>In article <654@caslon.cs.arizona.edu> Dave P. Schaumann writes:

[Text eliminated -- see references]

 >I think Dave expresses a deeper and more practical point: it is easier to
 >build a bridge, if you've built one before.  Building the first one may be
 >as much education as engineering, regardless of how good your engineering
 >handbook is.  Dave suggests expressing ones ideas into an implementation to
 >see what it will look like.  This is exactly (or close enough to) the
 >scientific method used when one is searching for solutions to a problem (or
 >testing a hypothesis).  

There is some confusion here between the roles of engineering and science.
Science is discovery through hypothesis testing (in books, anyway, where
serendipity is ignored); engineering fabricating from the known.  Engineers
build what they already know how to build, with only small differences
allowed between successive designs.  We would never award a contract to a
engineering firm that has never build a bridge before.

However, we let programmers hack away at things they've never built before,
on our money, and express surprise at the results.


>>A proper engineering anaylsis will generate and evaluate several solutions
>>whose implementations are fully known BEFORE specific implementation
>>(coding) begins.  Imagine buying, shipping, and erecting the steel before
>>the bridge is designed!
>
>This seems to be the key: are there well known solutions to the problem?
>Dave makes the point that it is tough to know if one even understands the
>problem.

If I don't have a well known solution to the problem, I shouldn't call what
I'm doing 'engineering'.  Engineering is problem setting, not problem
solving.


>"Print all numbers from 1 to a million" seems easy to code and has well
>known solutions, but the average programmer may not appreciate how big one
>million is.  

Whoa!  This is implementation-level stuff.  If this were a critical part of
a design, it would have not made it past PDR unless there were a bounded
solution.  And, if it's a critical task, we wouldn't give it to an 'average
programmer'.


>...So, if I don't recognize that I'm building a bridge, I may not look at the
>appropriate solutions.

If I don't recognize that I'm supposed to be building a bridge, perhaps I
shouldn't be in the gorge except to fish.


>>There are real engineering methods which help to answer the "best solution"
>>question above, but alas, we teach them only to engineering students.
>>Parnas took a good shot at this in the Jan. 90 issue of "Computer".
>
>In our rush to achieve engineering in software, we shouldn't automatically
>disdain the exploratory methods that are so useful when problems are not
>well understood.

A bit of non sequitor...please read the Parnas article!


Rich