Newsgroups: comp.edu,comp.object,comp.lang.c++,comp.lang.smalltalk,comp.software.testing
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!news-e1a.megaweb.com!newstf01.news.aol.com!uunet!in1.uu.net!projtech!steve
From: steve@projtech.com (Steve Mellor)
Subject: Re: Software Engineering Doesn't Exist [was: C Hackers]
Message-ID: <1995Jul21.221011.7219@projtech.com>
Organization: Project Technology, Inc., Berkeley, CA
References: <3uk6lr$1mv@bmerhc5e.bnr.ca> <3ulkoh$mui@handy.gr.com> <denatale-2107950011190001@grail519.nando.net>
Date: Fri, 21 Jul 1995 22:10:11 GMT
Lines: 50
Xref: glinda.oz.cs.cmu.edu comp.edu:13479 comp.object:35421 comp.lang.c++:139920 comp.lang.smalltalk:26208 comp.software.testing:5311

In a thread "Software Engineering Doesn't Exist [was: C Hackers]"
Rick DeNatale wrote:

> Any bridge designer who cares not what his bridges are to be constructed
> of is not going to design very successful bridges. If he designs it
> assuming that steel will be used and tin is substituted, the bridge will
> likely fall.
> 
> An Engineer even when designing with conventional materials and technology
> must be aware of the characteristics of the materials and the expected
> results of applying the appropriate techniques for working those
> materials.
In my opinion, these two paragraphs are contradictory.  In paragraph 1,
Mr DeNatale suggests that I need to know what the material is.
In paragraph 2 OTOH, he says that I need to know about the _characteristics_
of the materials.  These are different.  Do I want steel?  Or do I want
any material that has at least t tensile strength; withstand s1 stress,
and s2 strain; has a density less than d, etc etc etc?

I claim it's the latter.  Put yourself in the position of the materials
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??

> 
> In the real world design and implementation cannot be separated. It might
> seem that way if we are walking well known paths and have internalized the
> "rules of thumb" to the extent that we no longer realize how we are doing
> what we are doing, but just because the coupling might be subconscious
> doesn't make it less real.
> 

As a result of the unrecognized contradiction above, Mr DeNatale draws
a conclusion that is somewhat overstated.  It would be more accurate to say
that we should make explicit the assumptions about the implementation,
but we should not constrain it.

Software engineering methods attempt to determine what information should
be carried from step to step, and they (should) attempt to minimize
the amount of information, so that we can more easily manipulate it.
If you hold the view that you always need to know everything,
which I assume Mr DeNatale does, then you are drawn to the conclusion
asserted in the subject line "Software Engineering Doesn't Exist"

-- 
Steve Mellor                                 steve@projtech.com
Project Technology, Inc.               ...!uunet!projtech!steve
2560 Ninth Street, Suite 214             Voice: +1 510-845-1484
Berkeley CA 94710, USA                     Fax: +1 510-845-1075
 **** Training and Consulting in the Shlaer-Mellor method ****
