Newsgroups: comp.edu,comp.object,comp.lang.c++,comp.lang.smalltalk,comp.software.testing,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!solaris.cc.vt.edu!news.duke.edu!agate!library.ucla.edu!info.ucla.edu!csulb.edu!csus.edu!netcom.com!nntpuser
From: scottw@advsysres.com (Scott A. Whitmire)
Subject: Re: Software Engineering Doesn't Exist [was: C Hackers]
Message-ID: <nntpuserDCwMq5.685@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: <3vr5sm$g5u@Starbase.NeoSoft.COM> <3vriai$ajc@hamblin.math.byu.edu> <3vtpck$p9v@ornews.intel.com> <1995Aug5.090958.3125@prim.demon.co.uk>
Date: Sun, 6 Aug 1995 19:42:05 GMT
Lines: 54
Xref: glinda.oz.cs.cmu.edu comp.edu:13761 comp.object:36397 comp.lang.c++:142504 comp.lang.smalltalk:26810 comp.software.testing:5665 comp.software-eng:35484

In <1995Aug5.090958.3125@prim.demon.co.uk>, Dave Griffiths <dave@prim.demon.co.uk> writes:
>In article <3vtpck$p9v@ornews.intel.com> "Patrick D. Logan" <patrick_d_logan@ccm.jf.intel.com> writes:
>>
>>The Patterns movement is one (yet broad) effort toward finding "laws" that work.
>>There is a long way to go, if it is possible at all.
>
>I haven't read this Design Patterns book yet but was under the impression
>that it was about finding... well design patterns, and then applying them.

That's about as close as your going to get. It's akin to practices and techniques, not
immutable laws.

>Useful though that may be, it isn't a "law" because it depends on the
>software engineer having the discipline to apply them. And this is the problem
>with software. Self-discipline doesn't work. With the physical world, the
>discipline and laws are imposed by the nature of the real world. In another

That's not quite correct. The discipline came about during the early 1800s when briges
started falling out from under trains. The railroads were tired of losing those expensive
trains, and the public was tired of being put at risk. So, engineers started using a
more disciplined approach to engineering to avoid the CONSEQUENCES of failing to follow
the laws. The laws themselves were did not create the discipline - they were  always there.

Before the disciplined approach, engineering wasn't exactly trial-and-error, it was more
take-what-has-worked-before-and-extend-it-a-little. When an extension worked, it became a
design practice. When it didn't work, we had a disaster on our hands. As late as 1940,
when "Galloping Girdie" sank in Washington State, we were still applying the take-what-has-
worked-and-extend-it-a-little. The builders of the Tacoma Narrows had been successful with
their first two projects (one of which was the Golden Gate). So, they tried to slim the
roadway down some more, and forgot to account for the airfoil effect of the roadway.

All of this is to say that software is not the only discipline with these "problems." And
that immutable laws do not force obeyance in and of themselves.

>thread titled "Russian Dolls", I was wondering how we could create new
>constraints on what is possible in software. Seems to me we have to learn
>the lesson from success in engineering in the physical world and find ways
>to _force_ programmers to structure applications.
>

The only way I can think of is to make the consequences of failure more direct and serious.
I don't think forcing engineers to use a particular method is the answer. They just need
to be made accountable for their results. Even in civil engineering, you can break the 
rules, if your structure stands. If it fails, you have no defense - all of the 
responsibility is yours.


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.

