Newsgroups: comp.edu,comp.object,comp.lang.c++,comp.lang.smalltalk,comp.software.testing
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!EU.net!sun4nl!esatst!murray
From: murray@yc.estec.esa.nl (A Murray Davidson)
Subject: Re: Software Engineering Doesn't Exist [was: C Hackers]
Message-ID: <DCowx0.8I@yc.estec.esa.nl>
Date: Wed, 2 Aug 1995 15:41:24 GMT
References: <jnedzelDC2os8.FsM@netcom.com> <3uu6sg$c72@inforamp.net> <1995Jul28.213754.1451@projtech.com> <3vbq3b$it3@ixnews3.ix.netcom.com>
Organization: ESA/ESTEC/YC, Noordwijk, The Netherlands
Lines: 73
Xref: glinda.oz.cs.cmu.edu comp.edu:13683 comp.object:36198 comp.lang.c++:141933 comp.lang.smalltalk:26636 comp.software.testing:5572

In article <3vbq3b$it3@ixnews3.ix.netcom.com>,
Jonah Thomas <JEThomas@ix.netcom.com> wrote:
>In <1995Jul28.213754.1451@projtech.com> steve@projtech.com (Steve 
>Mellor) writes: 
>
>>erc@cinenet.net (Eric Smith) writes:
>>> Steve Mellor <steve@projtech.com> wrote:
>>> >designer.  Do you want to be told "The requirement is steel" or do
>>> >you want to the freedom to find the best material that meets the
>>> >true requirements??
> 
>>> "Steel" is like a software package.  That is, it's like a black box
>>> with certain properties.  You're saying you want to work with those
>>> properties rather than with that black box.  But the problem is that
>>> there are too many properties to make it convenient to work with them
>>> as a package unless you have a black box such as "steel".
>
>>Thank you!  Thank you for distinguishing between knowledge about the
>>thing--in this example steel--and properties of the thing, in the
>>example, density, stress, strain etc.
>>And you have a good point: One name for the collection of _properties_
>>could be "steel", but let's understand that this stands for "any 
>>steel-like substance" within constraints that you delineate later.
>

This seems to be one more example of muddling terminology between disciplines.
A component manufactured from (a) steel is a thing, steel itself is not.
Steel is a substance. In trying to stretch to an analogy with SE, one
might cast steel as the equivalent of the programming language from which
components can be crafted. But if you attempt to reason in this analogy
(changing material is equivalent to changing programming language) you'll
very rapidly get in a mess!

The repeated attempts to strain the analogies between civil or mechanical
engineering  and SE keep foundering on this sort of misunderstanding.

>This just doesn't seem to be going away. <sigh>  OK, I can't stand it 
>any more.  You guys are talking as if steel was a thing, like a stack or 
>a buffer.  "Steel" is a name for a bewildering variety of things with a 
>likewise bewildering variety of properties.  It isn't uncommon for 
>designs to specify a particular type of steel -- when a variety of 
>others would do -- for simplicity, and also to make sure that a 
>contractor didn't slip in something else that was cheaper but marginal 
>with performance.  (Inspection is necessary, too, but that's no help if 
>it wasn't specified in the first place.)
>
>If software engineering involved buying modules from the lowest bidder 
>over a noisy communication line, and the primary backup for exception 
>handling after mutual good will was the American legal system, we'd 
>start seeing a lot of specs like "T4 will be used for all loadbearing 
>links."  
>

Quite right!

In mechanical engineering disciplines, much of the "analysis" phase can
neatly be avoided by adhering to approved codes and procedures. [Code
doesn't refer to computer programs but to codified methods etc.] A
designer will specify (e.g.) that pipework and pressurised systems must 
conform to a particular ASME code in construction and inspection methods.
Similarly, welding and other construction procedures will be invoked.

The idea that the designer can supply annotated drawings invoking
designated materials and procedures and expect manufacturing to turn
out a correct and acceptable product (with inspection etc.) illustrates
the scale of the gap between mature engineering and SE - what would the
analogue look like in a software project?

Murray
-- 
-- 
Murray Davidson.  YCV Section, ESTEC, Post Box 299, 2200 AG Noordwijk, NL
murray@yc.estec.esa.nl      Tel. +31 1719 84025        Fax +31 1719 12142
