Software rot
From Wikipedia, the free encyclopedia
 |
This article or section needs copy editing for proper spelling, grammar, usage, tone, style, and voice. You can help by editing it now. A guide is available, as is general editing help. |
Software rot, also known as code rot or software decay, is a type of bit rot. It describes the perceived slow deterioration of software over time that will eventually lead to it becoming faulty, unusable, or otherwise in need of maintenance.
It is not, of course, possible for code to spontaneously metamorphose over time—save for issues such as the decay of magnetically stored data, quantum tunnelling, and similar effects, for which see bit rot. The real 'cause' of the rot is the advancement or change of the environment in which the software operates. When a change occurs, which the original program did not anticipate, the software may no longer operate as originally intended, and thus has 'rotted'.
Normal maintenance of software and systems do not cause rot as, when given proper consideration, the full impact of changes are taken into account and dealt with accordingly. However, it can be the case that unrelated systems are not updated as at the time of original change because they are not relevant. Later, the unrelated system may become relevant but not longer compatible.
Software rot comes in two forms:
Dormant Rot: Software that is not currently being used gradually becomes unusable as the remainder of the application changes. It has been observed that unused software has a half life of perhaps one year—that is, there is a 50% probability that it will be usable without further work after one year, 25% after two years, and so on.
Active Rot: Software that is being continuously modified tends to lose its integrity over time.
It is often said that "The software is not completed until the last user is dead", because software that is in use by many users will always generate requests for modifications to handle changing situations in a changing world, and users will ask for new features that they think (rightly or wrongly) will be useful.
As the software moves further away from its original design, assumptions made by the original designers may no longer be true. Likewise, as the world changes, other once-true assumptions in how the application will be used may no longer be true. Thus if nothing is done, the reliability suffers and the software is said to 'rot'.
Software developers are taught to fully understand a problem before programming it, and to keep accurate and complete software documentation. But in the pressure driven environment of an active development office, programmers are often under more pressure to start on the next urgent request than to go back and update documentation. Thus it can happen that on old code, there is no-one who understands how it works or even what a particular block does. To some extent, this can be alleviated by internal documentation and variable names being meaningful, likewise procedure names.
[edit] Example
Consider the following sequence of events
- A database is created, storing data in character set A.
- The database contains text representations of hexadecimal numbers (e.g. "1a2b3")
- It is decided to convert the alphabetical characters to uppercase (e.g. "1A2B3"), as this is more aesthetically pleasing.
- A tool "FixUPPER" is written to do this, dealing with character set A only.
- The database is converted to use character set B.
- Some data is accidentally loaded with lowercase characters in hexadecimal numbers.
"FixUPPER" cannot be used a second time to change the data, because it only supports character set A. Thus, it can be said to have rotted, although the actual cause was the conversion of the database to character set B.
[edit] Refactoring
Refactoring is the process of going through old code and optimising it by removing dead code and rewriting sections that have been modified extensively and no longer work efficiently—in the example above, it would be to convert "FixUPPER" to work with character set B. This is done less often that one might expect, not only because of time pressure but because of the risk of upsetting some process that is working reliably. "If it ain't broke, don't fix it." While refactoring is beneficial in the long term, in the shorter term the upside is often small (a small increase in speed?) while the downside is large (risk of introducing a bug).
Software rot slows once an application is near the end of its commercial life and further development ceases. Users have learned to work around any remaining bugs, and the package becomes very reliable as nothing is changing. This often leads to the new version (which is likely to have undiscovered faults) being unfavorably compared to the old (which is now stable).
