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

• Dr. Paul Stachour of the Honeywell Computer Sciences Center will speak about software maintenance

• He will provide a definition of software maintenance and contrast it with other forms of maintenance

• Dr. Stachour will discuss the four approaches (traditional, never, discrete and continuous) used in the software industry

• Dr. Stachour believes that today's reliability and the non-stop systems's requirements make the continuous approach the the only practical one. None of the other approaches allows the dynamic maintenance of running systems.

• He further believes that continuous maintenance is impossible on most of today's systems using most programming languages. He will describe in detail one well-know implementation of the continuous approach.

• This is a talk contrasting state-of-the-art with state-of-the-practice.

Background

• The material used in today's presentation is taken from twenty years of personal experience in designing, implementing and maintaining medium - and large-scale computer software. This experience is on a variety of operating systems from a variety of manufacturers using a variety of programming languages.

• This talk presents the results on introspection into computing practitioners ' attitudes and behaviors, not the results of planned experiments or theoretical research.

• All data presented today comes from the personal experience of the and represents (only) his own views of the processes and practices prevalent within the software industry.

Agenda

• Observation

• Definition

• Approaches

• Implementation of the Continuous approach

• Conclusion

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)

• Maintain

• 2b. To keep in a certain condition or position, especially efficiency, good repair, etc, as the state maintains the roads

• Maintenance:

• 1. a maintaining or being maintained; upkeep, support, defense, etc.

• Characteristics of Software maintenance

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 is all activities associated with the process of changing software.

• The general categories are "error-correction" and "remedying inadequacies".

• This includes all change associated with "bug fixes" to previous software, functional and performance enhancements, providing back-compatibility and covering up hardware errors, creating user-interface access methods and other cosmetic changes, and updating to a new method-of-performing a function.

Software Maintenance

• Axiom 1

  • An x that isn't designed to be maintained can't be maintained

• Observation

  • Most programs aren't designed to be maintained

• Corollary

  • Most programs are unmaintainable

• Observation

  • The only constant is change

• Question

  • Is it possible to design software so it can be maintained ?

• Answer

  • Yes it is. But we don't.

Approaches

• Approach 1: Traditional - Everyone's Senior project

  • Write software any way you like, and fix the bugs when you find them; if you can.

• Approach 2: Never - DoD Embedded Systems

  • Design perfect specifications and interfaces, never change them.

  • Change only the implementation, and then only for bug-fixes before the product is released.

• Approach 3: Discrete Approach - Batch Operating Systems

  • Define hard-and-fast, highly configuration-controlled interfaces to elements of software; massive all-at-once changes.

• Approach 4: Continuous Approach - Multics

  • Define both code and data interfaces that can evolve as changes happen

1) Traditional Approach

• Characterization:

  • Don't even think about the possibility of maintenance.

• Practice

  • Hard Coding of elements

    • Code

    • Data structures

    • No named constants

    • No macros

    • No subroutines

    • No local variables

  • No understandable organization

    • Names too short to be understood

    • No block or in-line comments

    • Incomplete separation of functions/operations

    • All modules dependent on externals

    • Gross mismatch between structure of problem and structure of solution

• Examples

  • we all know far too many.

• Notes

  • this is what most of us do at times.

2) "Never" Approach

• Characterization

• Practice

2) Never, Ctd.

• Examples

• Notes

  • Ada will be a tremendous help in this area.

3) Discrete Approach

• Characterization

3) Discrete, Ctd.

• Practice

• Never can the singe-step change be done

  • Multiple change interrelationships conflict

  • Networks mean multiple versions are simultaneously current

  • owners/users want to control change date

• Examples

  • IBM OS/360

• Notes

  • Experience shows that it is completely unrealistic to expect that all users of an interface (i.e., all users to whom an interface is visible) change at the same time.

4) Continuous Approach

• Characterization

• Practice

  • Weakly typed HLL and good macro assembler

4) Continuous, Ctd.

• Examples

• Notes

  • Hardware, operating systems, languages and practices all have a massive effect on the ease and efficiency of how one designs and implements software that one knows will change.

4a) Language

• Good languages

• Bad languages

• Reasoning

4b) Direct References

• Direct references destroy flexibility

• "Any solvable problem in computer science can be easily solved by the right number of levels of indirection" (Morven's Methatheorem), W. Morven Gentleman , University of Waterloo.

4b) Direct References, Continued.

• Indirect references provide changeability

4c) Data Structures

• Designed for expansion and change

• Implications

4c) Data Structures, Ctd.

• An example from Multics com_err_()

• Structure Elements

4d) Code Segments

• Self-identification

• Dynamically changeable

• Entry variables, e.g. PL/1

• Example

4e) Reference Philosophy

• The Method of Access is Important

• Don't make copies of objects; copies get out of synchronization

• If there is only one copy of something in a system/process, it can be upgraded more-or-less transparently

• This means not only objects, but reference to objects should have only one copy

Conclusion

• Software maintenance isn't hard, it's easy

• The theory and practice is more than ten years old [in 1984]

  • Note: no self- respecting data-processing manager would accept a first-generation vacuum-tube machine.

• Question: why do we as software professionals, allow ourselves to

Symptoms

• Get the software out now, and decide what its real function is later

• Don't provide any place or space for

  • Logging

  • Test-points

  • Debugging

in any delivered software

• Don't allow any room or facility for expansion

• Design and build the hardware first.

  • Later decide how to shoehorn the software in.

  • Then wonder how to sandwich the changes in.

• Chose a programming language that's inadequate to express either our application or packaging concepts.