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!swrinde!emory!cssun.mathcs.emory.edu!wa4mei!news.randomc.com!macshack.com!netcom.com!nntpuser
From: scottw@advsysres.com (Scott A. Whitmire)
Subject: Re: Software Engineering Doesn't Exist [was: C Hackers]
Message-ID: <nntpuserDC3p0G.CqL@netcom.com>
Sender: netnews@mork.netcom.com
Nntp-Posting-Host: advsysres.com
Reply-To: scottw@advsysres.com (Scott A. Whitmire)
Organization: Advanced Systems Research
X-Newsreader: IBM NewsReader/2 v1.09
References: <3uk6lr$1mv@bmerhc5e.bnr.ca> <3ulkoh$mui@handy.gr.com> <denatale-2107950011190001@grail519.nando.net> <1995Jul21.221011.7219@projtech.com>
Date: Sat, 22 Jul 1995 04:41:04 GMT
Lines: 82
Xref: glinda.oz.cs.cmu.edu comp.edu:13485 comp.object:35429 comp.lang.c++:139972 comp.lang.smalltalk:26215 comp.software.testing:5314

In <1995Jul21.221011.7219@projtech.com>, steve@projtech.com (Steve Mellor) writes:
>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?

No, they are NOT contradictory. Read them again. I had to. In building materials,
if you specify a tensile strength, stressability, strain resistance, and density,
you generally end up with one or two materials. From there, you use availability,
cost, or ease of working with it, to select one.

>
>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??
>

The structural engineer's job is to design the bridge to meet the required specificaions
and loads. Part of that job is determining the materials to be used.

>> 
>> 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.

There is no contradiction above. And I don't think the conclusion is overstated.
Isn't the point of design to determine the implementation that best meets the 
requirements? Analysis determines WHAT a system is to do (be it software, bridge,
business, or whatever), and design determines HOW the system does the WHAT. If you
separate design from implementation, you never get the thing built.

>
>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"
>

No, that's not quite right. While it is not necessary to know everything when you
start design, it is necessary to know everything when you finish it. And software
engineering does exists, but it is not a "what," it is a "how." You can build software
by "hacking" it together, or you can engineer it. Engineering implies formally (here
meaning deliberately) making tradeoffs among alternatives, using as objective and
quantitative methods as are available, in order to meet both the requirements and
the constraints. This involves some very deliberate actions such as analysis of a
design (walkthroughs, reviews, and inspections are examples), calculation of certain
measures, testing of hypotheses (which first requires MAKING those hypotheses), and
other actions (borrowed from the scientific method).


Scott A. Whitmire             scottw@advsysres.com
Advanced Systems Research     
25238 127th Avenue SE         tel:(206)631-7868
Kent Washington 98031         fax:(206)630-2238

Consultants in object-oriented development and software metrics.

