Software Aging – Parnas 1994

This paper contains one of my all-time favourite passages, and is a timeless discussion on why software ages, and what we can do to slow the aging process.

Programs, like people, get old. We can’t prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable.

If you’ve ever looked at some older software (for example, the recent bashing of bash) with horror, this quote is for you:

The authors and owners of new software products often look at aging software with disdain. They believe that, if the product had been designed using today’s techniques, it wouldn’t be causing problems. Such remarks remind me of a young jogger scoffing at an 86 year-old man (who, unknown to the jogger, was a champion swimmer into his 50s), and saying that he should have had more exercise in his youth.

What causes software aging? There are two fundamental reasons according to Parnas:

1. Failure of the product’s owners to modify it to meet changing needs, and
2. Changes that are made to the product 😉

And here comes my favourite passage, with apologies for the extended quote:

The designer of a piece of software usually had a simple concept in mind when writing the program. If the program is large, understanding that concept allows one to find those sections of the program that must be altered or updated when an update or correction is needed. Understanding that concept also implies understanding the interfaces used within the system and between the system and its environment. Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Under those circumstances, changes will be inconsistent with the original concept; in fact, they will invalidate the original concept. Sometimes the damage is small, but often it is quite severe. After those changes, one must know both the original design rules, and the newly introduced exceptions to the rules, to understand the product. After many such changes, the original designers no longer understand the product. Those who made the changes, never did. In other words, nobody understands the modified product!

Parnas discusses a number of techniques to mitigate aging, including designing for the long run, and confining decisions most likely to change to small areas of the code. Much easier said than done, and Parnas discusses what it takes to do this properly.

There are many other great quotes in the paper, here are some of my favourites:

Inexperienced programmers can often be recognised by the elation that they show the first time they get correct results from a program.

The only programs that don’t get changed are those that are so bad nobody wants to use them. Designing for change is designing for success.

Programmers tend to confuse design principles with languages. For example, they believe that one cannot apply ‘object-oriented’ ideas without using an ‘object-oriented’ language. Even worse, they think that one has applied the techniques, if one has used such a language.

… and a lovely throwaway line from when patching literally meant patching:

I can recall the days when a programmer would “patch” a program stored on paper tape by using glue and paper.