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

2. 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.

3. 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.

4. 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.

5. 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

6. 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!

7. 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

8. 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 one The cost of maintenance gets very high, it is no longer possible to keep up with the market on all the versions. Plus Developers move on to other projects Developers forget what they did and why they did it

9. 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”

10. 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

11. 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

12. 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

13. 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

14. 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.

15. What can we do to delay the decay and limit software aging’s effects Design for success The only software that does not change is software that is not used. Designing for change is designing for success Apply: Information hiding Abstraction Separation of concerns Data hiding Object orientation By characterizing the likely classes changes; estimate the probabilities of each type of change Organize the software to confine likely changes to a small amount of code Implement objects that hide changeable data structures Provide an abstract interface that abstracts from the changes

16. 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

17. 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

18. Keeping records – Documentation Design concepts and decisions are not recorded Documentation 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

19. 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

20. 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!

21. How to care for aging software: Stopping the deterioration This 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 reviewed The code must be checked to make sure that it has been made consistent with these new documents

22. 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

23. 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.

24. 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 program Examine the various versions to determine why they are different Replace 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”

25. 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 begins Changes have to be documented and reviewed A thorough analysis of future changes must be a part of every product design and maintenance action