Newsgroups: comp.software-eng
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!csn!arrayb!taylor
From: taylor@intellistor.com (Dick Taylor)
Subject: Re: bridge building (was Re: Documenting OO Systems)
Message-ID: <1991Apr25.200023.5334@intellistor.com>
Organization: Intellistor, Longmont, CO
References: <jls.672364339@rutabaga> <33407@mimsy.umd.edu> <jls.672529800@rutabaga>
Distribution: na
Date: Thu, 25 Apr 91 20:00:23 GMT

In article <jls.672529800@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>The high level of human creativity in every software
>>enterprise as compared to the creativity involved in a static structure like
>>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes.  
>
>You miss my point--the high level of creativity required in software is
>due to our not yet having a clue how to make writing software more like
>building bridges. Bridge builders were undoubtedly VERY creative before
>there was any grasp of how to build bridges.
>

Y'know, it occurs to me that your analogy is closer than you might think,
but not in a way that agrees with your central point.

I think that building _some_kinds_ of software is very much like building
bridges.  That is, the thing is expensive to produce, and so critical in
its function that any failure at all is potentially catastrophic and
certainly expensive.  Space shuttle operating software, for example,
fits nicely into this mold.

Other kinds of software may not have this level of expense and criticality. Or
they may not be susceptible to the same kind of orderly design methodology.

The problem with building everything as if it were a bridge is that bridges
cost lots to build (lots more per square foot than, for example, a parking
lot) and they take a lot of design and implementation time.  Civil engineering
has progressed to the point that bridges are built like bridges should be
built, buildings are build like buildings should be built, and parking lots
are built with as little effort as possible.  All done with good engineering.

I don't there there is or ever will be one and only one good method of
software engineering.  I think we do have a LONG way to go before we have
the methods as codified and tested as engineers in more concrete (ick. :-)
fields.  And I think your .sig indicates that you agree, or at least that
you quote someone who agrees:

>--
>* "Beyond 100,000 lines of code, you should probably be coding in Ada." *
>*      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *
>*                                                                       *
>*                The opinions expressed herein are my own.              *

That is, there are times when ANY software methodology may not work.
