The tendency of software that has not been used in a while to fail; such failure may be semi-humorously ascribed to bit rot
. More commonly, "software rot" strikes when a program's assumptions become out of date. If the design was insufficiently robust
, this may cause it to fail in mysterious ways.
For example, owing to shortsightedness in the design of some COBOL programs, many would have succumbed to software rot when their 2-digit year counters wrapped around at the beginning of the year 2000. A related incident made the news in 1990, when a gentleman born in 1889 applied for a driver's licence renewal in Raleigh, North Carolina. The system refused to issue the card, probably because with 2-digit years the ages 101 and 1 cannot be distinguished.
Historical note: Software rot in an even funnier sense than the mythical one was a real problem on early research computers (e.g. the R1; see grind crank
). If a program that depended on a peculiar instruction hadn't been run in quite a while, the user might discover that the opcodes no longer did the same things they once did. ("Hey, so-and-so needs an instruction to do such-and-such. We can snarf
this opcode, right? No one uses it.")
Another classic example of this sprang from the time an MIT
hacker found a simple way to double the speed of the unconditional jump instruction on a PDP-6
, so he patched the hardware. Unfortunately, this broke some fragile timing software in a music-playing program, throwing its output out of tune. This was fixed by adding a defensive initialisation routine to compare the speed of a timing loop with the real-time clock; in other words, it figured out how fast the PDP-6 was that day, and corrected appropriately.