bit rot

expression

programmingops culture

The way working software seems to decay over time as the world around it changes.

The bits do not literally rot, but dependencies move, platforms shift, and assumptions expire, so untouched code that ran fine last year now breaks. It is why 'if it works, don't touch it' is a trap - unmaintained systems rot precisely because everything else keeps moving.

Bit rot describes software that stops working despite nobody changing it, and the name is deliberately ironic since the bits are fine. What changed is everything around them: the operating system updated, a dependency shipped a breaking release, a certificate expired, an API deprecated the endpoint, the leap year arrived.

The important consequence is that unmaintained does not mean stable. A system nobody touches is not frozen, it is drifting relative to a moving environment, and the drift is invisible until something fails. This is why the code that has run untouched for six years is a risk rather than a reassurance, and why the phrase if it ain't broke don't fix it quietly assumes an environment that stands still.

There is a literal version too, and it is worth separating. Storage media genuinely degrade, and bits do flip in memory and on disk, which is what checksums, scrubbing and ECC exist to catch. Most people saying bit rot mean the metaphorical kind, but the physical kind is why a backup nobody has ever restored is not yet a backup.

Also known as: bit rot, software rot, code rot, link rot

All glossary entries