[comp.software-eng] Overengineering Software

skill@qucis.queensu.CA (David Skillicorn) (04/26/91)

A number of people have used metaphors for the robustness of software
based on physical processes such as bridge building. Such metaphors
contain some dangers since they tend to suggest that building software
is much like building bridges, and building in a little extra something
will increase the <insert nice property here> of the software.

The problem is that (all things being equal) real world systems are
continuous and have the property that a little bit more of something
in the building results in a little bit more of a nice property in
the final system. Software is not continuous and such properties are
uncommon and hard to work with. Two behaviours of the system that
are perceived by users to be very close by some appearance metric
may be wildly different in some metric suitable to the internal logic
of the program. 

Now it is possible to talk about the robustness of software in
terms of the size of the set of input/output states for which the
software is well-behaved; and hence in terms of predicates which
can be "weaker" or "stronger". But this doesn't seem to be quite what
people mean when they talk about "pushing the software". And, as
I've already suggested, it doesn't necessarily correspond very directly
to the external appearance of a "stronger" piece of software.

                           David Skillicorn
                           Queen's University

kend@data.UUCP (Ken Dickey) (04/30/91)

skill@qucis.queensu.CA (David Skillicorn) writes:

>A number of people have used metaphors for the robustness of software
>based on physical processes such as bridge building. Such metaphors
>contain some dangers since they tend to suggest that building software
>is much like building bridges, and building in a little extra something
>will increase the <insert nice property here> of the software.

I think that you are confusing the engineering practice of using
"excess capacity"  (e.g. for load bearing strength) with adding
materials or structural features.


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


>... Two behaviours of the system that
>are perceived by users to be very close by some appearance metric
>may be wildly different in some metric suitable to the internal logic
>of the program. 

As a "bridge" may span a small creek or the San Francisco Bay...

Perhaps the problem you are worried about may arise because the
metaphor is not followed closely enough!


-Ken Dickey				kend@data.uucp

mct@praxis.co.uk (Martyn Thomas) (04/30/91)

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.

There is an important point which may be being missed here.

The behaviour of materials is (close to) continuous, up to the point where
failure occurs. For example, a beam will bend to the point where it breaks.
This means that measurements of the behaviour of materials can be
interpolated. Extrapolation is more risky.

Software behaviour cannot even be interpolated. Consider a weighing machine.
If it is a balance beam, or an extending spring, it can be calibrated and
its accuracy determined by spot measurements and interpolation. If it is
digital, spot measurements only tell you about the accuracy at those exact
weights (and arguably, not much about that). It is perfectly possible that
values between the spot weights will be arbitrarily inaccurate, and only
analysis of the entire system can tell you more. That's one of the penalties
of digital systems.

So how do you certify digital weighing machines? By "engineering judgement",
I guess.

"When they talk about engineering judgement, I know they're just going to
make up numbers." (Richard Feynmann, writing about the Challenger Inquiry,
in 'What do you care what other people think?')


-- 
Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:	+44-225-444700.   Email:   mct@praxis.co.uk

koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/01/91)

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
exponential function for the amount of wood needed per dam size.
Give me some national forest and a saw and I'll build you Hoover
Dam (and about 100 years).  It's just probably cheaper to use
another material.  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).

Harry Koehnemann
koehnema@enuxha.eas.asu.edu

mjl@cs.rit.edu (Michael J Lutz) (05/01/91)

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