Software aging
A Socratic walk-through of software aging — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why does a phone or laptop grow slower over years when not one component has physically changed?
A three-year-old laptop runs the same instruction set at the same clock as it did on the first day. No transistor has worn out, no bit of the compiled binary has changed shape on the disk. And yet the same task genuinely takes longer. If nothing physical decayed and nothing in the code was rewritten, where exactly did the speed go?
"It got old" explains nothing, and "they slow it down deliberately" is an accusation rather than a mechanism. What we want is something that can grow without anything being added.
Reasoning it through
REASONING #Start with the smallest version of the phenomenon, because it is the cleanest. Take a single long-running process — a web server, a phone's media daemon — and leave it running for weeks with an unchanging binary and an unchanging workload. Its response times creep up, its memory footprint creeps up, and eventually it falls over. Nothing was edited. So what changed?
What changed is its state. A running program is not just code; it is code plus everything it has accumulated since it started. A block of memory allocated and never released — a leak — is the obvious residue, and only the beginning. Even a program that leaks nothing suffers fragmentation: memory comes back in the wrong order and the wrong sizes, so the heap becomes a cheese of free gaps too small to use, and the next request takes longer or fails outright while plenty of memory is nominally free. Add unclosed file handles, caches with no eviction policy quietly growing to fill memory, and log files.
Notice the shape of these: they are one-way. Each event is tiny and irreversible, and they only ever add. That is what lets degradation appear with no cause anyone can point at. There is no bug at any moment; there is only a sum.
So what fixes it? Ask what a restart actually does, and the answer is almost embarrassing: it discards the state and rebuilds it from the code, which never aged. And once you see that, you see that restarting need not be a defeat. If the decline is gradual and roughly predictable, you can restart before the failure rather than after it — a restart scheduled at 04:00 costs seconds, while a crash under peak load costs an outage. That deliberate practice is called software rejuvenation, a real technique with a literature behind it. Its trade is not less downtime overall but downtime moved from when the fault chooses to when you choose.
Now widen back to the laptop, and be honest that the answer becomes several answers wearing one costume. Some of the slowdown is process-level aging of exactly the kind above. Much is not. The installation itself has accumulated: more services registered at login, more extensions, indexes and caches sprawling, storage filling until the flash drive has less room to manoeuvre and writes slow. Some is that the software genuinely changed — updates arrive tuned for newer hardware, and the same web page carries far more code than it did three years ago. And some is comparison: the machine has slowed less relative to itself than relative to what you now expect of it. Those have different remedies, which is the practical reason for separating them. A reboot fixes the first, a clean reinstall the second, and nothing fixes the last two.
The analogy
THE ANALOGY #Think of a kitchen worked in continuously without ever being reset. No knife dulls, no pan warps — the tools are exactly as they were. But a jar goes back in the wrong cupboard, a drawer fills with things that have no home, the counter loses a corner to something nobody wants to decide about. Each event is trivial. After a year every task takes longer, and no single misplaced item is to blame; the cook is simply working around an accumulated arrangement. Clearing the kitchen back to empty is not a repair. It is a discard.
a kitchen's clutter is visible and can be tidied selectively, whereas a process cannot generally identify which of its own allocations have become dead weight — if it could, it would have freed them — which is exactly why the crude remedy of discarding everything is often the only reliable one.
Clarifying the model
THE MODEL #A caution about the name, because two different phenomena share it. The sense above — a running system degrading through accumulated state — is the one where rejuvenation applies. But "software aging" is also used, following Parnas, for something quite different: a codebase decaying relative to a world that keeps moving, as its assumptions expire, its dependencies go stale, and repeated ill-informed edits erode its structure. That is what people usually mean by code rot, and it is closer in spirit to technical debt. Keep them apart, because they fail and are fixed differently: the first is cured by a restart and nothing else, the second is untouched by a restart and cured only by editing the source. A program can be healthy as a codebase and dying as a process, or the reverse.
Two more refinements. Aging is not wear — there is no ratchet in the silicon, and a fresh install on the same hardware genuinely restores the speed, which is the cleanest proof that the loss was in state, not in matter. And "restart it" is not an admission that the software is bad. Any system holding state long enough drifts; deciding in advance how it returns to a known point is design, not surrender.
A picture of it
THE PICTURE #How to readStart at the black dot and follow the process through its life. The self-loop on Working is the healthy case, memory taken and given back in balance; the drift into Degraded is what happens when that balance is slightly imperfect and never corrected. From Degraded there are exactly two exits and they lead to the same place — rejuvenation is the discard-and-rebuild taken deliberately, Crashed is the identical transition taken at the worst possible moment. Nothing here repairs the state, because nothing can: every route back to Fresh throws it away.
What became clearer
WHAT CLEARED #The machine did not decay; its accumulated state did. Code is stateless in the sense that matters here — exactly as fast on day one thousand as on day one — so every gradual slowdown must live in something the system has piled up since it last started clean. That reframes the fix: you are not repairing anything, you are choosing when to discard. And it splits the laptop's vague complaint into separately treatable problems — a process to restart, an installation to clean, a codebase drifted from its environment, and an expectation that has quietly risen.
Where to go next
ONWARD #- How rejuvenation schedules are actually chosen, and why the optimum depends on the ratio of planned to unplanned downtime cost.
- Why garbage-collected runtimes suffer fragmentation differently from manual allocators, and what a compacting collector buys.
Key terms
TERMS #| Term | What it means |
|---|---|
| Memory leak | memory a program allocates and never releases, so its footprint only grows. |
| Fragmentation | free memory broken into gaps too small to satisfy new requests, wasting capacity that is nominally available. |
| Software rejuvenation | deliberately restarting a component before degradation causes failure, to convert unplanned downtime into planned downtime. |
| Code rot | decay of a codebase relative to its changing environment; the other, unrelated sense of "software aging". |
Every term the collection defines is gathered in the glossary.