Software rot

Not to be confused with Data degradation.

Software rot (bit rot, code rot, software erosion, software decay, or software entropy) is the degradation, deterioration, or loss of the use or performance of software over time.

From a software user experience perspective, it is operating environmental evolution inclusive of hardware. The first cause for the objective loss to the practical use of software is the loss of the host system as a practical operating environment.

The Jargon File , a compendium of hacker lore, defines "bit rot" as a jocular explanation for the degradation of a software program over time even if "nothing has changed"; the idea behind this is almost as if the bits that make up the program were subject to radioactive decay. ^[1]

Causes

Several factors are responsible for software rot, including changes to the environment in which the software operates, degradation of compatibility between parts of the software itself, and the emergence of bugs in unused or rarely used code.

Environment change

A screen recording of a bug introduced to Blender 2.9 as result of changes in AMD drivers, causing strobing dots of light and incorrect rendering of surface normals. Updates had to be made in Blender's code to accommodate these changes, fixing the bug.

When changes occur in the program's environment, particularly changes which the designer of the program did not anticipate, the software may no longer operate as originally intended. For example, many early computer game designers used the CPU clock speed as a timer in their games. ^[2] However, newer CPU clocks were faster, so the gameplay speed increased accordingly, making the games less usable over time.

Onceability

There are changes in the environment not related to the program's designer, but its users. Initially, a user could bring the system into working order, and have it working flawlessly for a certain amount of time. But, when the system stops working correctly, or the users want to access the configuration controls, they cannot repeat that initial step because of the different context and the unavailable information (password lost, missing instructions, or simply a hard-to-manage user interface that was first configured by trial and error). Information architect Jonas Söderström has named this concept onceability, ^[3] and defines it as "the quality in a technical system that prevents a user from restoring the system, once it has failed".

Unused code

Infrequently used portions of code, such as document filters or interfaces designed to be used by other programs, may contain bugs that go unnoticed. With changes in user requirements and other external factors, this code may be executed later, thereby exposing the bugs and making the software appear less functional.

Rarely updated code

See also: Dependency hell

Normal maintenance of software and systems may also cause software rot. In particular, when a program contains multiple parts which function at arm's length from one another, failing to consider how changes to one part that affect the others may introduce bugs.

In some cases, this may take the form of libraries that the software uses being changed in a way which adversely affects the software. If the old version of a library that previously worked with the software can no longer be used due to conflicts with other software or security flaws that were found in the old version, there may no longer be a viable version of a needed library for the program to use.

Online connectivity

Modern commercial software often connects to an online server for license verification and accessing information. If the online service powering the software is shut down, it may stop working. ^{[4] [5]}

Since the late 2010s most websites use secure HTTPS connections. However this requires encryption keys called root certificates which have expiration dates. After the certificates expire the device loses connectivity to most websites unless the keys are continuously updated. ^[6]

Another issue is that in March 2021 old encryption standards TLS 1.0 and TLS 1.1 were deprecated. ^[7] This means that operating systems, browsers and other online software that do not support at least TLS 1.2 cannot connect to most websites, even to download patches or update the browser, if these are available. This is occasionally called the "TLS apocalypse".

Products that cannot connect to most websites include PowerMacs, old Unix boxes and Microsoft Windows versions older than Server 2008/Windows 7 (at least without the use of a third-party browser). The Internet Explorer 8 browser in Server 2008/Windows 7 does support TLS 1.2 but it is disabled by default. ^[8]

Classification

Software rot is usually classified as being either 'dormant rot' or 'active rot'.

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.

Active rot

Software that is being continuously modified may lose its integrity over time if proper mitigating processes are not consistently applied. However, much software requires continuous changes to meet new requirements and correct bugs, and re-engineering software each time a change is made is rarely practical. This creates what is essentially an evolution process for the program, causing it to depart from the original engineered design. As a consequence of this and a changing environment, assumptions made by the original designers may be invalidated, thereby introducing bugs.

In practice, adding new features may be prioritized over updating documentation; without documentation, however, it is possible for specific knowledge pertaining to parts of the program to be lost. To some extent, this can be mitigated by following best current practices for coding conventions.

Active software rot slows once an application is near the end of its commercial life and further development ceases. Users often learn to work around any remaining software bugs, and the behaviour of the software becomes consistent as nothing is changing.

Examples

AI program example

Many seminal programs from the early days of AI research have suffered from irreparable software rot. For example, the original SHRDLU program (an early natural language understanding program) cannot be run on any modern-day computer or computer simulator, as it was developed during the days when LISP and PLANNER were still in development stage and thus uses non-standard macros and software libraries which do not exist anymore.

Forked online forum example

Suppose an administrator creates a forum using open source forum software, and then heavily modifies it by 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 accidentally make changes which conflict with each other or the original software, causing the forum to behave unexpectedly or break down altogether. This leaves them in a very bad position: as they have 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 patch may not be directly applicable to their code, requiring the administrator to effectively rewrite the update.
• The administrator who made the modifications could vacate their position, leaving the new administrator with a convoluted and heavily modified forum that lacks full documentation. Without fully understanding the modifications, it is difficult for the new administrator to make changes without introducing conflicts and bugs. Furthermore, documentation of the original system may no longer be available, or worse yet, misleading due to subtle differences in functional requirements.

Wiki example

Suppose a webmaster installs the latest version of MediaWiki, the software that powers wikis such as Wikipedia, then never applies any updates. Over time, the web host is likely to update their versions of the programming language (such as PHP) and the database (such as MariaDB) without consulting the webmaster. After a long enough time, this will eventually break complex websites that have not been updated, because the latest versions of PHP and MariaDB will have breaking changes as they hard deprecate certain built-in functions, breaking backwards compatibility and causing fatal errors. Other problems that can arise with un-updated website software include security vulnerabilities and spam.

Refactoring

Main article: Code 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 behaviour. ^[9] 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 behaviour, as this could introduce incompatibilities and thereby itself contribute to software rot. Some design principles to consider when it comes to refactoring is maintaining the hierarchical structure of the code and implementing abstraction to simplify and generalize code structures. ^[10]

Software entropy

Software entropy describes a tendency for repairs and modifications to a software system to cause it to gradually lose structure or increase in complexity. ^[11] Manny Lehman used the term entropy in 1974 to describe the complexity of a software system, and to draw an analogy to the second law of thermodynamics. Lehman's laws of software evolution state that a complex software system will require continuous modifications to maintain its relevance to the environment around it, and that such modifications will increase the system's entropy unless specific work is done to reduce it. ^[12]

Ivar Jacobson et al. in 1992 described software entropy similarly, and argued that this increase in disorder as a system is modified would always eventually make a software system uneconomical to maintain, although the time until that happens is greatly dependent on its initial design, and can be extended by refactoring. ^[13]

In 1999, Andrew Hunt and David Thomas use fixing broken windows as a metaphor for avoiding software entropy in software development. ^[14]

See also

• Code smell
• Dependency hell
• Generation loss
• Software bloat
• Software brittleness
• SOLID  – Object-oriented programming design principles

References

1. Raymond, Eric. "Bit rot". The Jargon File. Retrieved 3 March 2013.
2. Salemi, Joe (1992-01-28). PC Magazine. Ziff Davis, Inc. p. 286.
3. Jonas Söderström. "Onceability: The consequence of technology rot". Archived from the original on 2021-06-03.
4. Amadeo, Ron (31 October 2016). "The (updated) history of Android". Ars Technica. Retrieved 31 October 2021.
5. "Adobe CS2 is Now Available for Free, Sort Of". Mobile Magazine. 2013-01-14. Archived from the original on 2013-01-18. Retrieved 2013-01-20.
6. Paul Wagenseil (2020-12-24). "Apocalypse deferred: These Android devices will no longer go offline next fall". Tom's Guide. Retrieved 2023-03-16.
7. "RFC ft-ietf-tls-oldversions-deprecate: Deprecating TLS 1.0 and TLS 1.1". IETF Datatracker. 2021-03-23. Retrieved 2023-03-16.
8. "Windows 7 adds support for TLSv1.1 and TLSv1.2 - IEInternals - Site Home - MSDN Blogs". Archived from the original on 2013-12-26.
9. Fowler, Martin (October 11, 2007). "What Is Refactoring" . Retrieved 2007-11-22.
10. Suryanarayana, Girish, Ganesh Samarthyam, and Tushar Sharma. Refactoring for Software Design Smells : Managing Technical Debt / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1st edition. Waltham, Massachusetts ; Morgan Kaufmann, 2015. Print.
11. Tripathy, Priyadarshi; Naik, Kshirasagar (2014). Software evolution and maintenance: a practitioner's approach. Hoboken, New Jersey: Wiley. p. 376. ISBN   978-0-470-60341-3.
12. Lehman, M. M.; Belady, L.A. (1985), Program evolution: processes of software change, Academic Press, pp. 143–144, ISBN   9780124424401
13. Jacobson, Ivar; Christerson, Magnus; Jonsson, Patrik; Övergaard, Gunnar (1992), Object-Oriented Software Engineering: A Use Case Driven Approach , ACM Press. Addison–Wesley, pp.  70-72, ISBN   0-201-54435-0
14. Hunt, Andrew; Thomas, David (1999), The Pragmatic Programmer , Addison Wesley, pp. 4–6, ISBN   0-201-61622-X