Software rot
From Wikipedia, the free encyclopedia
 |
This article or section needs copy editing for grammar, style, cohesion, tone and/or spelling. You can assist by editing it now. A how-to guide is available, as is general documentation. This article has been tagged since January 2007. |
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.
Contents |
[edit] Causes
It is not possible for code to spontaneously metamorphose over time (save for physical deterioration of storage media, for which see bit rot). There are several factors responsible for software rot:
- Advancement or change of the environment in which the software operates.
- Less frequently updated portions of software tend to degrade as their compatibility with frequently updated modules decreases over time.
- Unused code is often not tested well enough and may contain unnoticed bugs.
[edit] Environment change
When changes occur in the environment of the program, especially changes the original program [design] did not anticipate, the software may no longer operate as originally intended, and this is seen as being similar to some perishable commodity 'rotting' over time.
[edit] Rarely updated code
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.
[edit] Unused code
Portions of code which are not traversed during the normal execution of a program may contain bugs that go unnoticed. With changes in user requirements and other external factors, this code may come into play later, thereby creating the illusion of deterioration.
[edit] Classification
Software rot is usually classified as being either Dormant Rot or Active Rot:
[edit] Dormant Rot
Software that is not currently being used gradually becomes unusable as the remainder of the application changes. Changes in user requirements and the software environment also contribute to the deterioration.
[edit] 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 old documentation. Thus it can happen that with an old code, there is no one who understands how it works or even what a particular block of code does. To some extent, this can be alleviated by internal documentation and variable names.
[edit] Example
Suppose an administrator creates a forum using phpBB or other online forum software. He or she then heavily modifies and "hacks" it, adding new features and options. This process requires extensive modifications to existing code and deviation from the original functionality of that software.
From here, there several ways software rot can affect the system:
- The administrator can try and add "one modification too many", and as a result of a conflict between two or several of those modifications, the forum may stop working properly or break down altogether. This leaves the administrator in a very bad position: as they've deviated so greatly from the original code, technical support and assistance in reviving the forum will be difficult to obtain.
- A security hole may be discovered in the original forum source code, requiring a security patch. However, because the administrator has modified the code so extensively, the upgrade is extremely difficult or impossible to do without tediously uninstalling several modifications first.
- The administrator who made the modifications could move on or quit the role, leaving the new administration team with a convoluted and heavily-modified forum which they might not be able to repair or upgrade due to simply not understanding exactly how or what has been changed.
[edit] Refactoring
Refactoring is the process of going through old code and optimizing 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).
