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 Universitykend@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