Software AgingBy David Lorge Parnas

Source: “Software Findamentals Collected papers by David L. Parnas.” Edited by Daniel M. Hoffman and Davic M. Weiss

Do software systems age analogously to human?

What Nonsense!

•Software is a mathematical product; mathematics doesn’t decay with time

•If a program is correct today, it will be correct 100 years from now

•If it is wrong 100 years from now, it must have been wrong when it was written

•It make no sense to talk about software aging

TRUE, BUT NOT REALY RELEVANT

Software does get old and it costs more in old age than it did at birth.

Do software systems age analogously to human?

What Nonsense!

•Software is a mathematical product; mathematics doesn’t decay with time

•If a program is correct today, it will be correct 100 years from now

•If it is wrong 100 years from now, it must have been wrong when it was written

•It make no sense to talk about software aging

TRUE, BUT NOT REALY RELEVANT

Software does get old and it costs more in old age than it did at birth.

Software products do exhibit a phenomenon that closely resemble human aging. Many products are now viewed as a burdensome legacy from the past. A steadily increasing amount of effort is going into the support of these older products.

Like human aging, software aging is inevitable, but like human aging, there are things that we can do to slow down the process and sometimes even reverse its effects.

The fact that software is now becoming a major “capital” of many high-tech firms. The aging of these products is impeding the further development of the systems that include them.

What causes software aging?

Two basic types of software aging:

• Failure to keep up with changing environment Unless software is frequently updated, its users will become dissatisfied and

they will change to a new product as soon as the benefits outweigh the costs of retaining and converting

• Tissue damage resulting from maintenance It is essential to upgrade software to prevent aging, changing software can

cause a different form of aging. But changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade.

Both lead to a decline in the value of a software product

Causes of software aging:

• Our expectations have changed

• We are no longer willing to use the clumsy software interfaces of yesterday

• We demand interactive access

• Old software would still do its job if used, but nobody would use it

• Old software must compete with new products

When changes are not made, it seems as if the software has aged!

More causes of software aging:

• Designers of software had simple concept in mind when writing the program

• Changes made without understanding design concept

• Changed code is inconsistent with original concept

• After changes, one must know both the original design concept, and the exceptions

• After more changes – NOBODY understands the modified product

When nobody understands the product• Changes take longer• Changes are more likely to introduce “bugs”

The problem is exacerbated when maintainers do not have time to update the documentation

More causes

Many companies allow the product line to split, with the second line inheriting the properties of the first. This policy leads to difficult to constrain, growth.

Changes must be made to many versions instead of just oneThe cost of maintenance gets very high, it is no longer possible to keep up with the market on all the versions.

PlusDevelopers move on to other projectsDevelopers forget what they did and why they did it

More Causes:

Bad documentation• Information not available• Information not correct• Information hard to find• Information must be verified• Information is not precise, easily misinterpreted

Documentation are not kept “alive”

The costs of software aging

Rising Maintenance Costs

• It harder to know where to make changes

• Changes are harder to make

• There are more errors

• Testing becomes more of a burden

• Documentation takes longer to update

Inability to keep up with others

• Newer products have desired features

• Newer products can be adapted more quickly

• Newer products win more market share

• Program size increased order of magnitude makes changes more difficult

Reduced performance

• The size of the program grows; more demands on the computer resource

• More demands on the computer memory, more delays caused by swapping

• Performance decreases because of poor (or poorly understood) design

• Customers must upgrade their hardware to get acceptable response -- leads to switch to newer products to obtain better performance

Decreasing reliability

• Errors are introduced; each error corrected may introduce more than one error

• Improvements can make things worse -- often the only choice was to abandon the product or at least to stop repairing bugs

• Large groups of people are devoted to customer requested repairs

Reducing the costs of software aging

Experience showed that any serious product requires extensive testing, review and revision after the first successful run.

The work that is invested by a development organization after the first successful run and before the first release is usually much greater than that required to get the first successful run. Most organization only focus on that first release

Experience with software aging tells us that we should be looking far beyond the first release to the time when product is old.

What can we do to delay the decay and limit software aging’s effects

Design for successThe only software that does not change is software that is not used. Designing for change is designing for success

Apply:Information hidingAbstractionSeparation of concernsData hidingObject orientation

By characterizing the likely classes changes; estimate the probabilities of each type of changeOrganize the software to confine likely changes to a small amount of codeImplement objects that hide changeable data structuresProvide an abstract interface that abstracts from the changes

Why the industry failed to apply these ideas?

Programmers are impatient with such considerations; they are eager to meet deadline, there is no time to design for change

Designs that result from a careful application of information hiding are not “natural” for many software designers

Designers mimic older designs

Many confuse design principles with choice of language

Many developers do not have the education appropriate to the job

There is no miracle drugs or quick fix to this problem

Good design is HARD, it requires:

• Careful consideration of possible changes

• Careful examination of constraints

• Careful design of interface

• Careful review

• Qualified people

Do not depend on languages, we must recognize that software problems never went away in spite of the introduction of FORTRAN, PL/I. ADA

Keeping records – Documentation

Design concepts and decisions are not recordedDocumentation is neglected by researchers and practitioners

• Documentation is usually poorly organized, incomplete and imprecise• Often the coverage is random, written when time and interest are there• Where documentation is a contractual requirement, it’s often done by a technical writer who does not understand the system

• Documentation that seems clear today, may be difficult to understand tomorrow

Documentation is not an “attractive” topic. But it is your responsibility as a software engineer to produce accurate design document and to keep them up-to-date

Second Opinions – reviews

Reviews are not standard practice among developers, why?

• Many developers have no professional training in software and the concept of preparing and holding a design review is non-existent

• Lack of documentation is review against

• Software is often produced under time pressure, leads to “short-cut”

Reviewer must represent long-term interests of the manufacturer or client

Review for ease of change must become standard

Software aging is inevitable

• Our ability to design for change depends on our ability to predict the future

• We will make changes that violate our original assumptions

• Documentation, even if formal and precise, will never be perfect

• Reviews will overlook some issues

• Preventive measures are worthwhile, but we cannot eliminate aging

We have to think about how to care for aging software!

How to care for aging software:

Stopping the deteriorationThis is done by introducing, or recreating structure whenever changes are made. Applying the same design principles, if a design decision about the system is changed, the new data structure or algorithm can be hidden(encapsulated) in a way that make any future changes of that aspect of the system easier. Careful reviews must ensure that each changes is consistent with the intent of the original designers.

New documents must be created and reviewedThe code must be checked to make sure that it has been made consistent with these new documents

Retroactive documentation

To slow the aging upgrade the documentation!

Correcting the documentation can be a major project, but worth undertaking

Redoing the documentation often leads to improvements in the software

Writing the documentation is a way to study and understand the software

It makes the next person’s job easier

Amputation

Some code has been modified so often and so thoughtlessly, it is not worth saving.

Often it should never have been written at all

Sections of code should be discarded and replaced by new code which perform the function in some other way.

Restructuring

When a large family of products gets out of control, a major effort to restructure it is appropriate.

First step – reduce the size of the programExamine the various versions to determine why they are differentReplace many versions with one by introducing “switches” that are checked at run-time to determine which version of behavior is wanted.

It often pays to ship the same code to everyone – even those who have not paid for all the features .. The features can be “turned off”

Planning ahead

If we want to prevent or at least slow down software aging, we must recognize it as a problem and plan for it.

We must imposing standards on structure and documentation

Design have to be documented, reviewed before coding beginsChanges have to be documented and reviewed

A thorough analysis of future changes must be a part of every product design and maintenance action