Software rot, also called bit rot or code rot, is the phenomenon in which a piece of software seems to get worse over time even though, in a literal sense, the source code on disk may not have changed. Programs do not corrode physically, yet working systems that were once reliable begin to fail, become hard to modify, or stop building at all. The term captures the lived experience of maintenance: code ages.
The foundational engineering treatment is David L. Parnas’s invited plenary talk “Software Aging,” delivered at the 16th International Conference on Software Engineering in 1994. Parnas, one of the central figures in software design, used the deliberately biological metaphor that programs, like people, get old. His paper is the primary source that framed software aging as a problem to be understood and managed rather than merely lamented, and it identifies the causes and the available countermeasures.
Parnas distinguishes two distinct mechanisms of aging. The first is caused by a lack of movement: the software stays the same while the world around it changes. The operating system is upgraded, hardware is replaced, libraries and dependencies evolve, data formats grow, regulations and user expectations shift, and the unchanged program drifts out of alignment with the environment it assumed. Code that compiled and ran perfectly years ago can fail today not because anyone touched it but because everything it depended on moved underneath it. This is the sense in which static software still rots.
The second mechanism is the opposite: damage done by the changes themselves. Parnas calls this ignorant surgery, modifications made by people who do not fully understand the original design. Each hurried fix or feature that is grafted on without respecting the program’s structure erodes the conceptual integrity that made the system comprehensible. Over many such edits the design decays, the documentation falls out of date, and the code becomes progressively harder and riskier to change, which in turn invites still more ignorant surgery. The system accumulates complexity and entropy until, eventually, it can become effectively unmaintainable.
Parnas argues that aging cannot be prevented outright, but its effects can be limited and partly reversed. The remedies are essentially good software-engineering discipline applied continuously: designing for change with clean module structure and information hiding, keeping documentation accurate, anticipating likely future modifications, and periodically investing in restructuring to undo accumulated damage before it compounds. He also stresses planning for the day a system is retired, since no software lives forever.
Software rot is closely tied to the idea of technical debt, where shortcuts taken under deadline accrue an interest cost paid later in slower, riskier maintenance (see technical-debt). It also connects to the broader concerns of software quality and to the maintenance realities that Fred Brooks described, in which the cost and difficulty of changing a large system grow as it ages (see mythical-man-month). Recognizing rot as a predictable process, rather than a surprise, is what lets teams budget for refactoring and modernization instead of waiting for a system to collapse under its own accumulated entropy.