Software rot
From Wikipedia, the free encyclopedia
 |
This article or section needs copy editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now. A how-to guide is available. (January 2007) |
 |
This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (July 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. This is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being updated with respect to the changing environment in which it resides.
Contents |
[edit] Causes
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 program's environment, especially changes which the designer of the program did not anticipate, the software may no longer operate as originally intended. This effect is analogous to a perishable commodity 'rotting' over time.
For example, many early game designers made assumptions about processing speed of the CPU which the games were designed for, causing the game to run too fast to be playable or exhibit other unwanted behavior when it is run on a far more advanced system than it was designed for.
[edit] Rarely updated code
Normal maintenance of software and systems may cause software rot. This is mitigated when the full impact of the changes are taken into account and dealt with accordingly.
For example, suppose that disparate parts of the system are updated at different times. If these changes are not considered as a whole, the changes may not be compatible with one another.
[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 be executed later, thereby creating the illusion of code 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 may lose its integrity over time, if proper mitigating steps are not taken.[citation needed]
It is often said that "The software is not completed until the last user is dead",[citation needed] because software that is in use by many users will always generate requests for modifications to handle changing situations in a changing world. Users will request new features that they believe (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 its environment changes, other once-true assumptions in how the application will be used may no longer be true.
Software developers are taught to fully understand a problem before programming it,[citation needed] 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. This leads to situations where, for example, there is no one who understands how old code works, or even what a particular block of code does. To some extent, this can be alleviated by software development best practices, such as internal documentation and variable names.
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 software 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).[citation needed]
[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 are 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 a means of addressing the problem of software rot. It is described as the process of rewriting existing code to improve its structure without affecting its external behavior.[1] This includes removing dead code and rewriting sections that have been modified extensively and no longer work efficiently. Care must be taken not to change the software's external behavior, as not to introduce bugs or other deficiencies in the place of software rot.
[edit] See also
[edit] References
- ^ Fowler, Martin (October 11, 2007). What Is Refactoring (HTML). Retrieved on 2007-11-22.
