The Universe Is Trying to Destroy Your Codebase
The Second Law of Thermodynamics isn't just physics — it's the most accurate description of what happens to every codebase over time. The parallels are too precise to be coincidence.
There is a law in physics so fundamental that it applies to everything in the observable universe — every star, every cup of coffee, every living cell. It says this: in any closed system, disorder always increases over time. You cannot stop it. You can only slow it down, and only by putting in energy.
That law is the Second Law of Thermodynamics. And if you've worked on a codebase for more than a year, you've felt it — even if you didn't have a name for it.
This post draws the parallels between physical entropy and what happens to software. Not as a metaphor. As a precise, predictive model for why codebases decay, why rewrites are exhausting, and what you can actually do about it.
First: What Is Entropy, Really?
Most people hear "entropy" and think "messiness." That's close, but not quite right.
Entropy is a measure of the number of possible states a system can be in. A crystal of ice has low entropy — every molecule is locked in a specific position. There's only one way for it to be arranged. A glass of water has higher entropy — molecules move freely, and there are billions of valid arrangements. Steam has even higher entropy — molecules spread out in all directions, an enormous number of possible states.
When physicists say entropy always increases, they mean this: systems naturally drift toward the arrangements that have the most possibilities. Order requires a specific, narrow configuration. Disorder has infinitely more ways to exist. So statistically, disorder always wins.
Now think about a codebase.
A fresh codebase is like a crystal. Clean modules. Clear boundaries. One way to do each thing. Every engineer on the team understands the whole picture. Entropy is low.
A five-year-old codebase — one that has shipped features, survived on-call incidents, absorbed the decisions of twenty different engineers across three major product pivots — that's steam. Modules reach into each other. The same concept is represented three different ways depending on when each piece was written. Nobody fully understands the whole picture anymore.
That's not bad engineering. That's physics.
The Parallel, Broken Down
Closed Systems Tend Toward Disorder
In thermodynamics, a closed system is one that doesn't exchange energy with its surroundings. A sealed thermos. A perfectly insulated box. In a closed system, entropy only ever increases.
A codebase that nobody actively maintains is a closed system. Nobody refactors. Nobody removes dead code. Nobody updates dependencies. Nobody cleans up the naming inconsistencies introduced when the product changed direction in 2022. Over time, disorder accumulates — silently, constantly, inevitably.
The dangerous thing about a closed codebase is that it looks stable from the outside. Nothing is breaking. Entropy doesn't make things break immediately. It makes things harder to change. And then, eventually, it makes things break in ways that are very hard to diagnose.
Technical Debt Is Entropy
Technical debt gets talked about as a financial metaphor — you borrow now and pay interest later. That framing is useful, but it misses something important.
Financial debt stays constant if you don't add to it. Entropy compounds. A messy module attracts more mess. Engineers working under time pressure will pattern-match to what's already there. If the existing code handles errors inconsistently, new code will handle errors inconsistently. If there's no clear owner for a cross-cutting concern, it gets duplicated. Each addition slightly increases the surface area of disorder.
This is why codebases that feel fine at year two often feel unmanageable at year five even if the rate of new features hasn't changed. The entropy is compounding in the background.
Heat Death Is the Unmaintainable Legacy System
The "heat death of the universe" is the theoretical endpoint of entropy — a state where everything is in perfect equilibrium, no useful energy gradients exist, and nothing can happen. Total, uniform disorder.
Every engineering organisation has a version of this: the system nobody touches. The one where changing a single line requires a week of archaeology. The one where the original engineer left three companies ago and the documentation says "see internal wiki" and the wiki link 404s. The one that runs in production because rewriting it is too scary, not because it's good.
That system has reached heat death. Its entropy is so high that extracting useful work from it — adding a feature, fixing a bug cleanly, onboarding a new engineer — costs more energy than it should. The system is technically alive, but thermodynamically dead.
Maxwell's Demon Is Your Code Review, Tests, and Linter
In 1867, physicist James Clerk Maxwell proposed a thought experiment. Imagine a tiny demon sitting at a gate between two chambers of gas. The demon watches molecules moving and only lets fast ones go right and slow ones go left. Over time, all the fast (hot) molecules are on one side — the demon has reduced entropy without doing work.
Maxwell's Demon was eventually debunked. The demon has to observe the molecules, which means storing information, which means expending energy. Reducing disorder always costs something.
Your CI pipeline is Maxwell's Demon. Your linter, your code reviewer, your automated test suite — these are mechanisms that detect disorder and reject it at the gate. A test that fails when someone introduces a regression is catching an entropy increase before it compounds. A code reviewer who asks "why is this handled differently from how we do it elsewhere" is reducing disorder.
But notice: this costs energy. Every test has to be written and maintained. Every code review takes time. Every lint rule has to be agreed upon and enforced. You cannot have Maxwell's Demon for free. The question isn't whether to pay the cost — you pay it either way. The question is whether you pay it upfront in reviews, or pay it later when the codebase becomes unmaintainable.
Refactoring Is Adding Energy to the System
To lower entropy in a physical system, you have to do work. A refrigerator moves heat from inside to outside — it doesn't destroy entropy, it exports it. The room gets slightly warmer so the inside can stay cold.
Refactoring is the same thing. You're not removing the complexity that accumulated — you're reorganising it, making it legible, exporting the disorder into deleted code. It costs engineering time. It requires understanding the current state deeply. It often involves temporary increases in disorder (the codebase is messy during a refactor) before the final state is cleaner.
This is why refactoring is always uncomfortable. It's not a sign of failure. It's thermodynamically necessary. A system that never gets refactored is a closed system that can only gain entropy.
The corollary: if your team never has time to refactor, entropy is accumulating. You're not "moving faster" — you're borrowing against a thermodynamic debt that compounds without mercy.
Open Systems: The Way Out
Here's the important physics. The Second Law applies to closed systems. Open systems — ones that exchange energy with their environment — can maintain or even decrease their local entropy, as long as they export enough disorder outward.
A living cell is an open system. It takes in food (energy) and outputs heat (entropy). Locally, it maintains exquisite order — proteins fold correctly, DNA replicates with high fidelity. Globally, it's increasing the universe's entropy. But the local order is real and useful.
You can design software systems to be more like open systems.
Clear module boundaries are entropy valves. When a module has a well-defined interface and a single responsibility, its internal disorder is contained. Changes inside don't leak into the rest of the system. You can refactor it — export its entropy — without touching anything else.
Microservices, done right, are open systems. Each service can evolve independently. Disorder in one service doesn't spread to others. You can even rewrite a single service from scratch (a local phase transition) without triggering a system-wide rewrite.
Strangler fig rewrites are phase transitions. In thermodynamics, a phase transition is when a system changes state — ice to water, water to steam. It requires a lot of energy and is temporarily chaotic, but results in a qualitatively different (and sometimes lower-entropy) state. A strangler fig rewrite does the same thing: you run the old and new systems in parallel, gradually routing traffic to the new one, until the old one can be switched off. It's expensive and uncomfortable, but it's a controlled phase transition instead of a catastrophic one.
Why Engineers Get This Wrong
The most common mistake is treating entropy as optional. Teams ship features, accumulate disorder, and tell themselves they'll clean it up "when things slow down." Things don't slow down. And entropy doesn't wait.
The second mistake is treating a rewrite as a solution. Rewrites have the same entropy dynamics as the original system. If you rewrite a messy monolith without changing the processes that made it messy, the new system will reach the same entropy level in roughly the same time. You've just reset the clock. A rewrite solves nothing on its own — it's a phase transition, not a physics bypass.
The third mistake is optimising for low entropy in the wrong place. Some entropy is fine, even necessary. A startup that writes perfectly clean code for features that might not survive the next pivot has made a bad trade. The goal is not zero entropy — it's minimising entropy in the parts that need to last, and accepting higher entropy in the parts that will be discarded.
What You Can Actually Do
The Second Law can't be repealed. But here's what you can work with:
Invest in Maxwell's Demons early. Tests, linting, code review norms, architecture decision records — these are mechanisms that catch entropy before it compounds. They're expensive to set up and cheap to run. The return compounds in the opposite direction from entropy.
Make the system more open. Every tight coupling is an entropy trap. Two modules that share mutable state, two services that call each other's internals, two teams that have to coordinate every change — these are closed subsystems where disorder accumulates faster. Add interfaces. Define ownership. Create seams where entropy can be exported.
Schedule refactoring like any other work. Not "when we have time" — time never appears. As a fixed allocation. Think of it as paying the energy cost required to keep the system open. If you stop paying, the system closes and entropy takes over.
Name the entropy. When a codebase is messy, engineers often feel vaguely bad about it but can't articulate why. Giving it a name — "our authentication module has high entropy, here's the evidence" — makes it legible to non-engineers and arguable in planning discussions.
The Honest Ending
Every codebase reaches heat death eventually. It gets rewritten or abandoned. This is not a failure of engineering. It is thermodynamics. The universe always wins in the long run.
What good engineering buys you is time. Time to extract useful work from the system before it becomes unmaintainable. Time for the product to find its shape. Time for the business to grow to the point where a proper rewrite is affordable.
The goal isn't to write code that never decays. It's to write code that decays slowly enough to be useful, and to do the work — continuously, unglamorously — that keeps the entropy from winning ahead of schedule.
The universe is trying to destroy your codebase. The best you can do is make it work for the effort.
