Software aging parnas

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. Inexperienced programmers can often be recognised by the elation that they show the first time they get correct results from a program. Designing for change is designing for success.

Programmers tend to confuse design principles with languages. Even worse, they think that one has applied the techniques, if one has used such a language. As the size of a program increases, inal concept. Sometimes the damage is small, but of- sometimes by one or two orders of magnitude over a ten it is quite severe.

After those changes, one must period of several years, changes become more diffi- know both the original design rules, and the newly in- cult in a variety of ways. First, there is more code to troduced exceptions to the rules, to understand the change; a change that might have been made in one product.

After many such changes, the original de- or two parts of the original program, now requires al- signers no longer understand the product. Those who tering man y sections of the code. Second, it is more made the changes, never did. In other words, nobody difficult to find the routines that must be changed.

As understands the modified product. Software that has a result, the owners are unable to add new features been repeatedly modified maintained in this way quickly enough. The company experi- Too many papers at software engineering confer- ences a notable drop in revenue; when they bring out ences focus on the problems of getting to the first re- a new version, it is of interest to a dwindling custom- lease.

Too many papers focus on the management er base. If they do attempt to keep up with the market, issues, e. It is customers. Performance also decreases because of 6. The software is no longer well under- The first step in controlling software aging is ap- stood and changes may adversely affect performance. The principle to be applied is known by vari- er or use less memory.

To apply this principle duced. Each time an attempt was made to decrease dictions will be about classes of changes, e. Often the expression representation, replacing of the terminal only choice was to abandon the product or at least to with a new type, changes in the user-interface, stop repairing bugs. I have been told of older software change to a new windowing system, etc. Since it is products in which the list of known, but not yet re- impossible to make everything equally easy to paired, bugs, exceeded entries.

In spite of the simplicity of this 1. The experi- principle, and in spite of its broad acceptance, I do just had a successful first demonstration enced programmer realises that this is just the begin- not see much software that is well designed from this ning.

They know that any serious product requires point of view. The work that is invested by responsi- principle. However, even experienced programmers focus trate, the process of estimating the probability of on that first release.

Our experience with software ag- change for various classes of changes. The princi- ing tells us that we should be looking far beyond the ple is simple; applying it properly requires a lot of first release to the time when the product is old. I suspect that some programmers think that The textbooks do not make that clear.

This is foolish. Designing for change is de- they do not take the time to design for change. Man- signing for success. It is not likely changes. Often the cov- Designers tend to mimic other designs that they erage is random; a programmer or manager decides have seen.

One example of information that a particular idea is clever and writes a memo hiding design is [9] about it while other topics, equally important, are ig- Programmers tend to confuse design principles nored. In other situations, where documentation is a with languages. Even worse, they think mentation. The resulting documentation is ignored that one has applied the techniques, if one has used by the maintenance programmers because it is not ac- such a language.

Some projects keep two sets of books; there is Many people who are doing software development, the official documentation, written as required for the do not have an education appropriate to the job.

Each industry has its own authors is often about as clear as mud to the program- software conferences and many programmers in mer who must maintain the code 6 months or 6 years each industry work as if their problems were later.

Even when the information is present, the main- unique. They are wrong! His answer was that was properly designed from this point of view. The it would not be interesting. I objected, saying that code is often clever, efficient, and correct; it performs there were many interesting aspects to this topic. His rather amazing functions, but rarely is it designed to response was that the problem was not that the dis- be easily changed. We have in software at all. We have invented and illus- tion.

Some were mathematicians, and some came from non-technical backgrounds. In many of those trated new mathematical notation that is much more areas, the concept of preparing and holding a de- suited to use in documentation, but no less formal sign review is nonexistent. As the list is a bit too dry, I will try to enhance it by bringing examples from the Java world, demonstrating the relevance or irrelevance of the causes.

Memory leaks. This is our current bread and butter — each day I face tens of different situations where applications are suffering from the leaks. Following sample illustrates the case. The program reads one number at a time and calculates its square value.

But since these results are never read from the cache, the code block represents a memory leak. It serves as a good sample of the aging — this program could be used for days before the end users are affected. Lock contention. You must all have been in the situation where the application behaves just fine for years and then after a small bump in load you start facing situations where the threads start waiting behind synchronized blocks and are either starved or completely locked out.

The following sample serves as a textbook illustration to the case. The code will work just fine until you launch two threads which attempt to run transfer a,b and transfer b,a at the same time resulting in a deadlock.

And again, you could be happily running the code for months or years before a situation like this escalates to locked threads. Unreleased file handles. Again, I am sure you have been cursing when looking at something similar to the following where a fellow developer has forgotten to close the resources after loading.

The code might have been running happily for months, before the java. IOException: Too many open files message is thrown which again serves as a good case demonstrating the aging problem. Modern OS tend to quickly page out memory that has not been touched for a while.

A major step in slowing the aging of older software, and often rejuvenating it, is to upgrade the quality of the documentation. Often, documentation is neglected by the maintenance programmers because in their haste to correct problems reported by customers or to introduce new features demanded by the market.

When they do document their work, it is often by means of a memo that is not integrated into the previously existing documentation, but simply added to it. If the software is really valuable, the resulting unstructured documentation can, and should, be replaced by carefully structured documentation that has been reviewed to be complete and correct. Often, when such a project is suggested, programmers who are rarely enthusiastic about any form of documentation scoff at the suggestion as impractical.

Their interests are short-term interests, and their work satisfaction comes from running programs. Nonetheless, there are situations where it is in the owner's best interest to insist that the product be documented in a form that can serve as a reference for future maintenance programmers.

If a product is not documented as it is designed, using documentation as a design medium, we will save a little today, but pay far more in the future. It is far harder to recreate design documentation than to create it as we go along. Documentation that has been created after the design is done, and the product shipped, is usually not very accurate. Further, such documentation was not available when and if the design was reviewed before coding.

As a result, even if the documentation is as good as it would have been, it has cost more and been worth less. I used to pass by a large computer system with the feeling that it represented the summed-up knowledge of human beings. It reassured me to think of all those programs as a kind of library in which our understanding of the world was recorded in intricate and exquisite detail. I managed to hold onto this comforting belief even in the face of 20 years in the programming business, where I learned from the beginning what a hard time we programmers have in maintaining our own code, let alone understanding programs written and modified over years by untold numbers of other programmers.

Programmers come and go; the core group that once understood the issues has written its code and moved on; new programmers have come, left their bit of understanding in the code and moved on in turn. Eventually, no one individual or group knows the full range of the problem behind the program, the solutions we chose, the ones we rejected and why.

Over time, the only representation of the original knowledge becomes the code itself, which by now is something we can run but not exactly understand. It has become a process, something we can operate but no longer rethink deeply. Even if you have the source code in front of you, there are limits to what a human reader can absorb from thousands of lines of text designed primarily to function, not to convey meaning. The underlying problem is obvious. Get past the flashy graphics and fancy user interfaces, and you frequently descend into a nightmarish realm of twisted spaghetti-like code that might better belong in a Salvador Dali painting.

One recurring type of software security bug, buffer overflows, dates back to the dawn of computing. A plethora of patches will never be a substitute for true quality software. We've all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined.

If it was, it may have eroded beyond recognition. What does this muddy code look like to the programmers in the trenches who must confront it? Data structures may be haphazardly constructed, or even next to non-existent.