Multics > Library > Articles
26 Mar 1984

Observations about Software Maintenance

David Collier-Brown

Back in 1984, I was at HI-Multics when Paul Stachour gave a talk on maintenance to the local university and the Ada SIG.

It contrasts the Multics approach to maintenance with the other, less successful ones. I've been showing it to people ever since, often to tease Unix bigots, but primarily to keep the idea of doing maintenance the right way alive.

This year, I dug it out once more, typed it in and got Paul's permission to submit it to you.

Observations about Software Maintenance

By Paul D. Stachour

Honeywell Computer Sciences Center

March 26, 1984

Abstract

Background

Agenda

Statement

Software is the only industry where the equivalent of adding a six-lane automobile expressway to a railroad bridge could even be classified as maintenance.

Definition of Maintenance (Webster)

  • a) It does not wear out in a physical sense

  • b) any aging characteristics are easily bypassed

  • c) most "Real Maintenance" is for implementation errors

  • d) also Requirement/Design errors

  • e) enhancement (New Function)

  • f) whimsical change (including people/procedures/laws)

Observation

Maintenance in other professions and of other articles is concerned with the return of the item to its original state; in Software, maintenance is concerned with moving an item away from its original state (From a presentation by Les Belady.)

Definition of Maintenance (Stachour)

Software Maintenance

Approaches

1) Traditional Approach

2) "Never" Approach

  • Design "perfect" specifications

  • Validate specifications against the real-world

  • Code to these specifications

  • Verify the code against the specifications

  • Test "forever" to find compiler errors / os problems / timings

  • Never change once running

  • Specification frozen, but faulty

  • Specification unvalidatable

  • Specifications not adhered to when code is written

  • Program not proven correct

  • Testing continues so long that programs are late

  • Replaced as a complete entity

2) Never, Ctd.

  • DoD embedded systems

  • Microwave ovens

  • Washing machines

3) Discrete Approach

  • Accept (reluctantly) the fact of change

  • Keep a parts-list and tools-list on every item

  • Allow only pre-authorized changes

  • Interface and functions statically configuration controlled.

  • All servers/user change in one discrete step

3) Discrete, Ctd.

  • Change happens more often and in more places than predicted

  • All components of an item are not recorded

  • Patching is alive (and unfortunately thriving) due to time-lag for authorization and rebuild-time for system

  • Official interfaces controlled, unofficial interfaces proliferate, varying problems later

  • Data structures so "available" that even when change is desired, it is impossible to change due to impact

4) Continuous Approach

  • Understand that the only constant is change

  • Migration (for hardware, software and function) during system operation is necessary

  • Change must be designed from the very beginning

  • No direct reference to anything if it can be avoided

  • Every data structure designed for expansion and self-identifying as to version

  • Every code segment built self-identifying by the compiler or other construction procedure

  • code/data changeable on a per command/process/system basis

  • As few copies a possible of anything (reference philosophy) which can be dynamically updated as necessary

4) Continuous, Ctd.

  • ARPANET Backbone (BBN)

  • Honeywell Multics (MIT/GE/Bell)

4a) Language

  • Macro assembler

  • Weakly typed HLL

    • C

    • PL/1

  • Totally untyped languages

    • BCPL

  • Strongly typed languages

    • Pascal

    • Ada

  • Controlled, checkable change is needed

  • Untyped: no control

  • Strongly typed: too much control



4b) Direct References

  • Literal constants

  • Static array bounds

  • Enumeration realizations

  • Supervisor call numbers in instruction

  • Descriptor references in instruction

  • Static procedure binding

  • Static storage binding

4b) Direct References, Continued.

  • Symbolic constants

  • Array bounds via attributes or language functions

  • All machine instructions take parameters rather than implied addresses

  • Procedures are called indirectly and dynamically linked

  • Storage bound through process registry, not OS allocations

4c) Data Structures

  • Absolute requirement

  • Example: based structure in PL/1

  • Contain version numbers (version identification)

  • Version numbers checked

  • Obsolete versions rejected

  • Not-quite-current version processed differently

  • Not-quite-current can be upgraded

  • Unimplemented versions rejected

  • Many different versions can exist simultaneously while upgrades take place at the user's convenience

  • Upgrades can happen automatically

  • Non-locality doesn't cause problems

  • Even non-obsolete versions or not-yet-available versions from sources like save-0taps is handled without any data-smashing

4c) Data Structures, Ctd.

  • dcl 1 query_info aligned,

    • 2 version fixed bin, /* Fixed-point binary */

    • 2 switches aligned,

      • 3 ..

  • Version is the version number of the structure. (input) The version number must be set by the caller and identifies the format of the structure. The current version is a static variable named query_info_version_ in query_info.pl1.

4d) Code Segments

  • Name

  • Version

  • Built by compiler or construction system

  • Per-process settable

  • (Example: always call user-shell instead of system-command-processor)

  • System installable/ deinstallable

  • Non-current version retained and used

  • Multics system install mechanism (slow change)

  • Multics process initiate/terminate mechanism (fast change)

4e) Reference Philosophy

Conclusion

  • One answer: We did it so badly at first (or were forced to do so badly at first by inadequate and incomplete hardware ) that we painted ourselves into a corner, with no way to get out.

  • Another answer: It's to the benefit of a giant in the industry to make it impossible for users to move away from its hardware/software because it would cost the user too much to re-write everything (I only half believe this one)

  • A third answer: We've grown so fast that we haven't taken time to learn our own minimal past; our teachers don't even know we're all (including me) working in the era of the Barber Surgeon.

  • My own answer: I don't. I refuse. If I can't get a Multics or a Symbolics Lisp machine or a Macintosh or some other half-reasonable system, I'll quit.(However, I do limp along on some half- baked systems for some of my work. But I'll never accept it)

Symptoms

in any delivered software