Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!rit!cs.rit.edu!mjl
From: mjl@cs.rit.edu (Michael J Lutz)
Newsgroups: comp.software-eng
Subject: Re: Overengineering Software
Message-ID: <2304@cs.rit.edu>
Date: 1 May 91 13:01:39 GMT
References: <1828@qusunita.queensu.CA> <482@data.UUCP> <9104302306.AA02217@enuxha.eas.asu.edu>
Sender: news@cs.rit.edu
Reply-To: mjl@cs.rit.edu
Organization: Rochester Institute of Technology
Lines: 74

In article <9104302306.AA02217@enuxha.eas.asu.edu>, koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) writes:
> In article <482@data.UUCP> kend@data.UUCP (Ken Dickey) writes:
> >skill@qucis.queensu.CA (David Skillicorn) writes:
> >
> >
> >>... Software is not continuous ...
> >
> >Neither is the strength of materials.  Classical example: a large
> >number of small dams have been built in this country with wood.  For a
> >large dam (e.g. Hoover), you don't add more wood.  The scale requires
> >the use of different materials.
> 
> It's not that you couldn't though, right?  It's is probably some
> ... Unfortunately, in the software industry,
> choices like these are not available, so we end up building
> all our dams out of wood (more like toothpicks).

Actually, the choices are available -- there are different degrees
of formality and structure that are appropriate to different
software products (or different dams).  However, what I find most
fascinating (and often galling) is that software systems are seen
purely as a cost, not an investment, so that it is rare that a system
that has reached the limits of evolution will actually be retired
and replaced by a new system that reflects the current state of
affairs.

To stretch the dam analogy a bit: it's as if a wooden dam originally
designed for a water-powered sawmill evolves into Hoover dam, but
the engineers at each step are required to use the existing base.
In this case, you would get a huge, wooden dam---probably of
mediocre caliber---when the correct choice at some point was to
blow up the wooden dam and start using concrete.

This issue, of course, and others like it, are from the area of
software evolution.  As an educator, what concerns me most is that
the issues of evolution are given at best cursory attention in most
books on software engineering, whereas in my (industrial) experience
such systems predominate.  Few programmers/engineers really start
from scratch: almost always there is some existing artifact that
must be modified rather than replaced.  Yet few methods or
methodologies admit this fact, much less address it.  Object-oriented
design, for all the hype, is one that *does* take the issues of
evolution seriously.  Yet even OOD gives few guidelines as to when
a system should be retired and replaced rather than modified, and
without such guidelines it is difficult to convince management
that continuing modifications are a bad investment.

In closing, I note that software development appears to be unique
in this regard, in that once a civil engineer has designed and
built a bridge, he/she can learn from it, leave it behind, and
go on to the next (hopefully better) bridge.  Similar things apply
in computer engineering: the designers of the Sun-2 learned from
this, and then could apply what they learned to the Sun-3's, which
in turn provided grist for the Sun-4's.  However, each generation
started with essentially a clean slate: no one made the Sparcstation
designers start with the schematics for the 3/50.  Yet I find it
ironic that this whole series of workstations runs an operating
system, Unix, whose design principles are fundamentally governed by
the technology of 1971.  Indeed, for all the restructuring of the
kernel done by Sun, AT&T, and others, the overall architecture (and
even key portions of the implementation) are essentially those
found in Version 6, which I first saw in 1976.  Even given the
superb skills of Ritchie and Thompson, and assuming that the Unix
API is still a good one, I'd say it's probably time to rethink how
the kernel itself should be organized.  In contrast, IBM CPUs,
which claim instruction set compatibility back to the 360 series,
do not carry the 360 baggage over into the design and
implementation of the newest processors.

---------
Mike Lutz
Rochester Institute of Technology
Rochester, NY 14623-0887
mjl@cs.rit.edu