Wikipedia's definition of software rot focuses on the performance of the software. This is a different usage than I am used to; I had thought of it much more in terms of the cleanliness and design of the code—in terms of the code's having all the standard quality characteristics: readability, maintainability, etc. Now, performance is likely to go down when the code becomes unreadable, because no one knows what is going on. But does the term software rot have special reference to performance? or am I right in thinking it refers to the cleanliness of the code? or is this perhaps a case of multiple senses of the term being in common usage—from the user's perspective, it has do with performance; but for the software craftsman, it has to do more specifically with how the code reads?
Lets face it. "Software rot" is not a well-defined technical concept. It is more of a pejorative description of what happens when software is poorly maintained.
The Wikipedia page represents one view, but there are clearly alternative views. And you could say that the different views reflect the different priorities and concerns of the person holding the views:
Someone who is focussed on making software fast will be more inclined to look for evidence of "software rot" in performance.
Someone who is focussed on design / architecture (e.g. because they need to add new functionality or fix functionality bugs), will see "software rot" from that perspective.
And, it is not really useful to say whose perspective is more right. (It is kind of like arguing whether turquoise is more green or more blue.)
I'd say that the term "software rot" refers generally to suitability for the task at hand. Software may become less suitable for its intended task due to layer upon layer of bug fixes, new features, and minor tweaks. Taken together, those can adversely affect both maintainability and performance. Also, the needs of the organization will likely change over time, and the software may be forced into roles that it was never really designed for. All these factors result in the software becoming less suitable to the organization's needs, and that can happen even with a concerted effort to maintain the software.
Wikipedia says that software rot and code rot are the same. I disagree.
Code rot is the gradual loss of readability and maintainability as more and more changes are made to the code.
Software rot is the gradual loss of performance as software is moved from one environment emulator to another. One example is all of the Data General PDP software running on emulators. Actually, it's the environment that's rotting, not the software.
Software doesn't actually go bad, get stale, wear out or "rot" in the traditional sense.
If the environment in which software operates doesn't change, the software will essentially last forever. This is why I get so peeved when someone asks if some library is "dead" because the author hasn't made an update to it in the last 5 minutes (exaggerating only slightly for effect).
But the environment usually does change; operating systems are patched and updated, computers get replaced with more powerful ones, and new programs get installed (like the latest version of a client like Internet Explorer, device drivers or other libraries), on which the software may depend. So the software must be updated to take into account those changes.
There are software systems that have been running continuously and reliably for literally decades without being significantly updated or maintained. COBOL software running on mainframes that handle bank transactions come to mind (although they all had to be modified in 1999 to handle Y2K).
Wikipedia's emphasis on performance seems to be missing the point; many software applications actually get a performance boost when they get installed in a newer environment. The Wikipedia article actually seems more concerned with software bloat.
"Software rot" - is very vague term and can mean variety of thing to anyone, depending on how is your perception of the concept, as well as, what is your view angle.
Definition by Wikipedia on Software rot does not set a standard as it is also written by some individuals. I think this term has variety of meaning and needs to be broken down to the specific areas, where it is refereed.
- Programmers may understand this as an un-maintainable code base with full of anti-patterns, no consistency in naming and coding style.
- System admins may understand this as bad performance, full of memory leaks and hell. maintenance.
- End-user may understand this as very complicated, non-intuitive, hard-to-work software.
I had always thought of software rot as a condition that occurs when you don't use software for a period of time. Somehow, the software morphs into a state where it is unbuildable. Then when you get it to a point where you can build it, it doesn't work with the inputs and outputs like it previously did. It's almost as if the code actually degraded in form even though it's stored digitally.