You shipped it on a Friday. It passed every test, the dashboards were green, and the team went home feeling good. Eighteen months later nobody dares touch the billing module. Nothing “broke.” No one made a single reckless decision. The system just got worse, one reasonable change at a time.
Physicists have a name for that pattern, and it isn’t “bad luck.” It’s entropy. This article borrows the idea from thermodynamics and asks a blunt question. If disorder is the default state of the universe, can any piece of software ever be truly permanent?
What Entropy Actually Means (Without the Physics Degree)
Most people describe entropy as “disorder,” which is close enough to be useful and wrong enough to mislead. The more precise idea comes from Ludwig Boltzmann. Entropy measures how many microscopic arrangements of a system look identical from the outside. A tidy desk has few arrangements that count as “tidy.” A messy desk has astronomically many that count as “messy.” Systems drift toward messy because there are simply more ways to be messy.
The second law of thermodynamics says that in an isolated system, total entropy never decreases. Heat flows from hot to cold. Ice melts in a warm room, and the reverse never happens by itself. Coffee does not spontaneously reheat.
Here is the part that matters for engineers. Order is not forbidden. A refrigerator makes ice in a warm kitchen all day long. But it pays for that local order by pushing more disorder out into the world, in the form of waste heat and electricity consumed. Order always has an energy bill.
Software Is Not Isolated, and That Changes Everything
A fair objection arrives here. A codebase is not a gas in a sealed box. It sits in a repository, and people edit it. So does the second law even apply?
Strictly speaking, no. Software entropy is an analogy, not a literal application of Boltzmann’s equation, and anyone who tells you otherwise is selling something. But the analogy holds up well, because software systems share the key structural features of thermodynamic ones. They have a huge number of possible states, only a tiny fraction of which are “good.” They are acted on constantly by outside forces. And they require continuous input from outside to stay organized.
Think of a codebase as a refrigerator, not a sealed box. It can stay ordered, but only while the energy keeps flowing in. In software, that energy is human attention, review time, test infrastructure, and money.
Lehman’s Laws: The Software World Noticed First
Engineers did not need a physics textbook to see this. In the 1970s, Meir Lehman and László Belady studied the evolution of large systems at IBM and formulated what became known as Lehman’s laws of software evolution. Two of them read almost like thermodynamics in disguise.
The law of increasing complexity says that as a system evolves, its complexity grows unless deliberate work is done to reduce it. The law of continuing change says a system in real use must be continually adapted, or it becomes progressively less useful. Put those together and you get the software version of the second law. Left alone, a working system either stagnates or rots, and changing it carelessly makes it rot faster.
If you want a deeper reading list on this, the original research on software evolution laws is still worth your time.
Where the Disorder Comes From
Entropy in software rarely arrives as a dramatic failure. It seeps in through at least four channels, and you have probably met all of them.
Internal Decay: Code Rot From Within
Every change adds a few more branches, a few more special cases, and a few more places where one module quietly knows too much about another. Ward Cunningham’s famous technical debt metaphor captures the financial side of this. Each shortcut is a loan, and the interest compounds as complexity.
The thermodynamic reading is subtler. A clean design is a low-entropy state, with few arrangements that satisfy all the constraints. Each hasty patch moves the system into a more probable, messier state. You never decide to make things worse. You just keep choosing the nearest working option, and the nearest working option is almost always the messy one.
External Decay: The World Moves On
Here is the uncomfortable truth. Your code can stay byte-for-byte identical and still decay. Operating systems change. Browsers deprecate features. A TLS version gets retired. The library you depend on gets abandoned, and a transitive dependency three layers down ships a breaking change.
Researchers sometimes call this “software rot” or “bit rot,” though the bits themselves rarely flip. What changes is the environment around them. The code is a key, and the lock keeps being replaced.
Knowledge Decay: The Quietest Leak
Systems also run on human understanding, and that understanding evaporates. People leave. Documentation drifts out of sync with reality. The original reasoning behind a strange design choice vanishes, and what remains is a comment reading “do not remove, nobody knows why.”
This is perhaps the purest form of information loss. You can have every line of source code and still have lost the system, because the model of it in human heads is gone.
Scale Decay: Success Is a Stressor
Growth itself adds disorder. More users, more integrations, and more teams mean more interactions between parts. The number of possible interactions grows far faster than the number of components, which is why a system of fifty services is not just “five times harder” than one of ten.
The Energy Cost of Staying Ordered
If entropy is the default, then order is something you buy. So what does the purchase look like in practice?
Refactoring is the obvious one. It reduces internal complexity without changing behavior, which is exactly the software equivalent of running the refrigerator. Test suites act as a kind of error-correcting code, catching the moment the system drifts out of its intended state. Dependency updates, security patches, and migration work all pay down environmental entropy. Documentation and onboarding pay down knowledge entropy.
None of this produces new features, and that is why it is chronically underfunded. Teams get praised for what they add and rarely for what they prevent from falling apart. The thermodynamic framing helps here because it reframes maintenance. It is not a tax on progress. It is the cost of existing at all in an environment that pushes back.
Is there a way to estimate how much maintenance is “enough”? Plenty of industry surveys claim maintenance consumes the majority of total software lifecycle cost, with figures like 60 to 80 percent circulating widely. I would treat those numbers cautiously. They trace back to older studies with differing definitions of “maintenance,” and I have not verified a single authoritative source for the exact range. The direction is solid, though. Across decades of studies, maintenance consistently outweighs initial development.
Maxwell’s Demon and the Value of Information
There is a famous thought experiment in physics called Maxwell’s demon. A tiny being sorts fast molecules from slow ones, seemingly creating order for free and violating the second law. The resolution, worked out through the efforts of Leo Szilard, Rolf Landauer, and Charles Bennett, is that the demon must acquire and eventually erase information, and erasing information costs energy.
Landauer’s principle puts a floor on it. Erasing one bit dissipates at least kT ln 2 of energy, where k is Boltzmann’s constant and T is temperature. That is a vanishingly small number per bit. But it ties information and thermodynamics together in a way software people should appreciate, because it means computation itself is a physical process with a physical cost.
A good engineering team behaves like a well-run demon. It spends effort gathering information through monitoring, tracing, and code review, then uses it to sort good states from bad ones. The sorting is never free.
Can Software Ever Be “Permanent”?
Now to the question in the title. Can we build software that simply lasts?
The honest answer has two layers. As an abstract object, a program can be eternal. The algorithm for computing the greatest common divisor is as true today as it was when Euclid described it. A mathematical specification does not rust.
But software as people actually use it is a running process on physical hardware, in a changing environment, serving people whose needs shift. That version of software is a dissipative structure, a pattern that persists only while energy flows through it, like a flame or a whirlpool. Stop the flow and the pattern collapses.
So “permanent software” in the sense of set-and-forget is thermodynamically off the table. Hardware wears out. The universe is not kind to stationary patterns. And even a perfectly preserved program needs something to run on and someone to interpret what it means.
The Counterexamples That Prove the Rule
Look at the systems we celebrate for longevity. NASA’s Voyager probes, launched in 1977, are still operating, and engineers have pushed software updates to them across billions of miles. That is not permanence. It is decades of careful, expensive, human-driven upkeep by people who understand the system deeply.
The same goes for the old mainframe languages and systems still running in banks and governments. You will often see claims about how many billions of lines of COBOL remain in production. Those figures vary wildly between sources, and I would not quote one without tracing it. What is well established is that these systems survive through a dedicated, aging workforce and constant care, not through some immunity to decay. When the people who understand them retire, the entropy catches up fast.
Longevity, in other words, is never a property of the code alone. It belongs to the code plus the ongoing effort around it.
Designing for Decay Instead of Pretending It Won’t Happen
If permanence is out, what should we do instead? Accept the physics and design around it. A few principles follow naturally from the thermodynamic view.
First, reduce the surface area exposed to the environment. Fewer dependencies mean fewer external locks that can change. Every library you add is a thread connecting your system to someone else’s entropy.
Second, keep boundaries clean. Strong modular design limits how far disorder can spread, much like insulation limits heat transfer. When one component rots, a good boundary keeps the damage local.
Third, make the cost of order cheap and routine. Automated tests, continuous integration, and scheduled dependency updates turn maintenance from heroic rescue missions into steady background work. A small, constant energy input beats a massive, occasional one. Anyone who has tried to catch up on three years of skipped upgrades knows why.
Fourth, treat knowledge as infrastructure. Write down the why, not just the what. Record decisions and their context. A lightweight architecture decision record practice is one of the cheapest anti-entropy tools you can adopt.
Finally, plan for retirement. Part of managing entropy is knowing when the cost of maintaining a system exceeds the value it delivers. Deliberately decommissioning software is not failure. It is the equivalent of letting a flame go out when the fuel is no longer worth burning.
A Practical Mindset Shift
Next time a stakeholder asks why a “finished” system needs ongoing budget, try this framing. We do not pay to improve it. We pay to keep it from sliding back toward the state the universe prefers. It is the same reason you keep cleaning your house even though you cleaned it last month.
That conversation goes better when you can point to something bigger than team preference. The research on long-term software sustainability backs the argument, and it is hard to dismiss an argument rooted in physics.
Conclusion
We started with a system that rotted quietly after a successful launch, and we ended up in the second law of thermodynamics. Along the way, a few ideas stood out.
Entropy explains why disorder is the default. There are simply far more broken or messy arrangements of a system than good ones, so drift is the expected outcome. Software evolution studies, from Lehman’s laws to the technical debt metaphor, describe the same tendency in engineering terms.
Disorder enters through four doors: internal complexity, a changing environment, lost knowledge, and growth. And because software is not an isolated system, order is possible, but it always costs energy in the form of refactoring, testing, upgrading, and documenting.
Finally, permanence is an illusion for any software that actually runs in the real world. Abstract algorithms can be timeless, but running systems are flames that need fuel. The best teams stop fighting that fact. They keep the maintenance cost low and steady, protect their knowledge, and know when to let a system go.
So the real question is not whether your software will decay. It will. The question is whether you will notice the decay while it is still cheap to fix.
