Xref: utzoo comp.object:3269 comp.software-eng:5415
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object,comp.software-eng
Subject: Re: Documenting OO Systems
Message-ID: <1139@tetrauk.UUCP>
Date: 18 Apr 91 08:14:27 GMT
References: <jls.670709095@rutabaga> <3201:Apr705:40:4591@kramden.acf.nyu.edu> <STEVE.91Apr15150739@diana.Advansoft.COM> <1991Apr16.124522.16592@dg-rtp.dg.com>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 47

In article <1991Apr16.124522.16592@dg-rtp.dg.com>
		cole@farmhand.rtp.dg.com (Bill Cole) writes:
>
> [...] Many times, the solution to a problem is nothing short of
>the 'eureka' moment, that golden moment of insight that brings an
>unexpected fix to a difficult problem.  If we were strictly engineers,
>we could down a catalog of routines and, by cleverly sticking them
>together, build a program.  Each programmer has a catalog of routines
>they've either learned or built, it's true, and you could argue that
>this constitutes a form of engineering catalog that EEs or CEs use to 
>build computers or buildings.  The difference is that programmers are
>tasked to build new components if they can't find one in the own catalog
>of program components.  How many CEs build bridges out of self-designed
>components?  

I think all fields of engineering require a measure of creativity to be
successful, it's not exclusive to sofware engineering.  Thinking of
auto-engineering, there are a number of landmark innovative cars which changed
the rule book - the VW beetle and Alec Issigonis' Mini are just two examples.
These cars weren't made by assembling all the standard bits from the catalogue;
they were the result of saying "why not do it like this instead? - I don't care
if it hasn't been done before!".  The _engineering_ is then applying the
knowledge of the underlying science - calculating stresses, etc - so that the
new components for the new design can be built.  This is what pioneers do;  the
followers then copy the ideas, and use these new components, or more likely the
component _designs_, to build the copies.  Soon the new bits are part of the
standard catalogue.

Engineers in all disciplines can and do come up with novel designs, and if the
components for what they want don't exist, they build them.  Perhaps the
difference is that they look for existing components first, and resort to
building them only if they don't already exist.  But more significantly, even
if they do build their own components, in most cases they will use standard
_designs_ to build them from.

Software at all levels is a design process, _not_ a production process.  So the
magical notion of "reuse" is a reuse of design, which may or may not exist in
the form of actual compilable source code.  Which brings us full circle - the
most important aspect of technical software documentation, OO or otherwise, is
the description of the design principles of the module rather than the actual
implementation mechanism.

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem