Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.software.testing
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!newsserver.jvnc.net!newsserver2.jvnc.net!howland.reston.ans.net!EU.net!sun4nl!esa.nl!esatst!news
From: murray@yc.estec.esa.nl (Murray Davidson)
Subject: Re: Theory and Practice [was: Beware of "C" Hackers -- A rebuttal to ...]
Sender: news@yc.estec.esa.nl (News from Usenet)
Message-ID: <DBI9Lw.Lu5@yc.estec.esa.nl>
Date: Mon, 10 Jul 1995 14:58:44 GMT
References: <3tdfsd$nn9@newsbf02.news.aol.com> <DBCHK2.MLH@hpqmoea.sqf.hp.com>  <Pine.A32.3.90.950707172725.22358A-100000@elvis.med.Virginia.EDU> <3tkbd7$72@nt.colmicrosys.com> <3tm6pi$ska@ornews.intel.com>
Nntp-Posting-Host: nt1.yc.estec.esa.nl
Organization: ESA-ESTEC
X-Newsreader: News for Windows NT X1.0-62
Lines: 95
Xref: glinda.oz.cs.cmu.edu comp.object:34797 comp.lang.c++:137568 comp.lang.smalltalk:25682 comp.software.testing:5085

In article <3tm6pi$ska@ornews.intel.com>
"Patrick D. Logan" <patrick_d_logan@ccm.jf.intel.com> wrote:

>khathi@ee.net (Kamal Hathi) wrote:

>>Software *Engineering* unfortunately is a gross misnomer. I am an 
>>Electrical Engineer by education (undergraduate) and also have 
>>training (post-graduate education and other) and experience as a
>>"Software Engineer". One thing I can categorically state is that 
>>developing software and the education in that field is closer to
>>art or language (as in english) than Engineering. Engineering is
>>an *exact science*, with a certain degree of inexact creative
>>license thrown in for good measure. Software Engineering is 
>>mostly a set of inexact and flexible *techniques* with some 
>>exactness thrown in.
>
>I have to disagree with this for many kinds of engineering work.
>
>For example, from what I have observed as a software developer 
>who has spent most of his career in the EDA industry, designing 
>a new microprocessor or ASIC is like designing a new software
>application *EXCEPT* the requirements are usually better understood
>and the raw material is more of a constraint on the solution.
>
>That is, in software applications the requirements are usually
>more vague and broad and the raw material (i.e. source expressions
>as opposed to transistors & gates, etc.) is more forgiving.
>
>But software design *is* a kind of engineering. It is more complex
>and less understood, but... oh, well, you'll either agree or disagree
>so I'll stop here.

I find statements about the exactitude of engineering (or of any other science,
for that matter) rather disturbing.

Many branches of engineering can be characterised (amongst others) as follows:

    - they impose degrees of tolerance upon values (e.g. the diameter of
      a tube shall be 20.0 +/- 0.01 mm);

    - they have standard codes or rules for the calculation of behaviour
      of materials or parts or structures (or etc...) which assume tolerances
      are respected to a certain confidence level;

    - designs (are supposed to) allow degradation rather than catastrophic
      failure;

    - the effect of overloading or incorrect application (analogous to invalid
      usage in software) is failure to operate, degradation or non-catastrophic
      failure;

    - when mission critical products are concerned, quality control on as many
      aspects as necessary to ensure the reliability figure (assessed against
      particular identified failure modes) is imposed.

There is one difference of principle between manufactured engineering products
and software - when series production is involved, testing and QA are used to
filter out those combinations of components whose tolerances mismatch or which
simply out of spec.

The glaring difference with S/W engineering is that we rarely have "components".
Certainly, components do not exhibit tolerance ranges with confidence levels
in their quality since they are identical copies (there is no manufacturing run).

Even in one-off structures, there is always the concept of "margin" of
performance against environmental conditions or user application.

Even in the calculations performed to demonstrate margin (where testing is not
possible or is not economically reasonable), engineering remains inexact. The
results, based on certain hypotheses, will demonstrate a degree of margin in
performance (strength, lifetime, signal handling, bandwidth or whatever) that
is justified as adequate through sensitivity analysis (playing with the
dispersions of critical values).

The analogue which might be introduced for systems (programs) based on components
is of graceful degradation of performance in place of failure. This would require
a degree of fuzziness in specification - certainly, algorithmic specification of
functionality and performance do not admit of a close analogy with normal
engineering. A more component-centric view of software construction with ranges
of interface conditions being tolerated rather than hard or exact values would
then result. [A lot of this is probably more familiar to those working in
(distributed) simulations or distributed systems generally.]

In summary:

    - real engineering is *fuzzy* and not exact;

    - software needs a big shift in world view to become real engineering.

Murray

Murray Davidson		European Space Agency Research and Technology Centre
murray@yc.estec.esa.nl	ESTEC, Postbox 299, 2200 AG Noordwijk, Netherlands
These are my thoughts and opinions, not ESTEC's.

