Developers spend about 42 percent of their working week, roughly 17 hours, on maintenance and dealing with bad code rather than building new features, according to Stripe's 2018 Developer Coefficient report. That number is entropy at work. Software entropy is the tendency of any...
Developers spend about 42 percent of their working week, roughly 17 hours, on maintenance and dealing with bad code rather than building new features, according to Stripe's 2018 Developer Coefficient report. That number is entropy at work. Software entropy is the tendency of any working system to drift toward disorder over time unless someone keeps putting energy in to hold it together. A system left alone does not stay the same. It decays.
I study behavioral psychology, and I find the entropy analogy useful because it removes blame. Your systems are not falling apart because your team is careless. They are falling apart because that is what systems do. Understanding the physics changes how you budget for the work that resists it.
In physics, the second law of thermodynamics says that the entropy of an isolated system left to evolve on its own cannot decrease. It tends toward a state of maximum disorder called equilibrium, as the standard formulation puts it. A hot cup of coffee cools to room temperature. It never spontaneously reheats itself.
Software borrows the word directly. The term is software rot, also called code rot or software entropy, and it describes the gradual degradation of a system's quality and usefulness over time. Nothing physically breaks. The code that shipped last year is the same code. What changes is everything around it.
The comparison is an analogy, not a law of physics, because a business system is not a closed system. You can add energy to it. That is precisely the point. Order in software is not the default state you fall into. It is the state you pay to maintain.
The most rigorous account of this drift comes from Manny Lehman and Laszlo Belady, who studied how large software systems evolve and published a set of observations now known as Lehman's laws of software evolution. Two of them explain almost everything you feel as your tools age.
The first is the law of continuing change. A system embedded in the real world "must be continually adapted or it becomes progressively less satisfactory." Your accounting rules change. A vendor updates an API. A regulation shifts. The software that fit your business last year fits it a little worse today, not because it changed, but because the world around it did.
The second is the law of increasing complexity. As a system evolves, "its complexity increases unless explicit work is done to maintain or reduce it." Every fix, every new feature, every patch adds a little intricacy. Left unmanaged, that intricacy compounds until the system becomes hard to change at all. The two laws work together: you are forced to keep changing the system, and each change makes the next one harder.
This is why the phrase "explicit work" matters so much. Complexity does not stabilize on its own. Someone has to spend deliberate effort refactoring, simplifying, and removing, or the intricacy keeps climbing. That deliberate effort is the energy input, and skipping it is exactly how technology fragmentation takes hold across a business.
Entropy in software is quiet. There is no alarm the day a system tips from healthy to fragile. The most useful mental model for the slow version comes from Andrew Hunt and David Thomas in The Pragmatic Programmer, who borrowed the broken windows theory from research on urban decay.
One broken window in a building, left unrepaired, signals that nobody is paying attention. Soon there are more broken windows, then graffiti, then serious damage. In software, a single messy shortcut that nobody cleans up sends the same signal to the next person: quality does not matter here. The next shortcut comes easier, and the decline accelerates. The window itself is rarely the real damage. The signal it sends to everyone who sees it is.
The authors are blunt that the biggest driver of rot is not technical. It is human. Neglect accelerates decay faster than any other factor, and team culture, not the code itself, decides whether the first broken window gets fixed. That is a psychology problem wearing an engineering costume, and it responds to the same discipline you would apply to the sunk cost fallacy running your technology stack.
The cost of ignored entropy is measurable, and it is large. McKinsey surveyed 50 CIOs at companies with revenues over a billion dollars and found that they estimated technical debt at 20 to 40 percent of the value of their entire technology estate before depreciation. For a large organization, that is hundreds of millions of dollars of accumulated disorder.
The drag is ongoing, not one-time. The same research found that 10 to 20 percent of the technology budget meant for new products gets diverted to resolving problems tied to existing debt. McKinsey calls this the complexity tax that every project pays, and 60 percent of the CIOs surveyed felt their debt had grown noticeably over the previous three years. Entropy compounds. The tax rises.
Ward Cunningham gave this its most durable name. As Martin Fowler explains, Cunningham coined the technical debt metaphor in a 1992 OOPSLA report: the extra effort it takes to add new features is the interest you pay on the debt. You can borrow deliberately to ship faster, but if you never pay down the principal, the interest keeps rising until the whole system is slow to change. This is one reason we tend to advise starting small, as I argued in the case to start with a monolith rather than a sprawl of services you cannot yet maintain.
Here is where the physics analogy earns its keep. If entropy is the natural drift toward disorder, then maintenance is the energy you put in to reverse it. Order does not persist for free. It persists because someone spends effort keeping it. Maintenance is not the thing that competes with real work. It is the work that makes all the other work possible. A tidy kitchen at the end of every shift is not lost cooking time. It is the reason the next shift can cook at all.
Most organizations budget backward on this. They fund the launch and treat upkeep as a cost to minimize, which is exactly why so many automated systems quietly decay after go-live. I have written before that automation maintenance is the job, not the launch, because an automation left untended does not hold steady. It drifts out of sync with the reality it was built for, one API change and one edge case at a time.
The Pragmatic Programmer's practical rule is to fix each broken window as soon as you find it, or at least board it up visibly so the decay does not spread. That is cheap when the flaw is small and fresh. It gets expensive in exact proportion to how long you wait, because complexity accumulates on top of it. Small, continuous energy input beats a heroic rescue later, every time. A rewrite is what happens when a business skips maintenance long enough that the interest finally comes due all at once.
Resisting entropy is not a project you finish. It is a cadence you sustain. A few practices make the difference between a system that ages gracefully and one that rots.
Schedule the maintenance instead of hoping for it. Reserve a fixed slice of every cycle for refactoring, dependency updates, and cleanup, and protect it the way you would protect a client deadline. Lehman's law of increasing complexity says the intricacy climbs unless explicit work reduces it, so the work has to be on the calendar, not left to spare time that never arrives.
Keep the number of moving parts honest. Every tool, integration, and service you add is a new surface for entropy to act on. Consolidating what you can and keeping data in order both slow the drift, which is part of why data governance is the real prerequisite for AI and why disconnected data ends up more expensive than missing data. Fewer parts means fewer windows to break.
Be deliberate about what you take on. Not everything should be built, and not everything should be automated, because each new system is a standing maintenance obligation. Knowing which of the tasks you should never automate is entropy management done in advance. So is resisting the pull to keep a homegrown tool alive past its usefulness, the pattern behind the endowment effect in the self-hosting decision.
The goal is not a system that never changes. Lehman's first law makes clear that is impossible for anything doing real work. The goal is a system that changes on purpose, with the complexity checked at every step, so the drift toward mess never gets ahead of the effort holding it back. That steady discipline is most of what good engineering actually looks like day to day, and it is the quiet foundation under everything we run at LTFI and share through kief.dev.
Software entropy is the tendency of a working system to drift toward disorder over time. The code itself does not change, but the world around it does, and every fix or feature adds complexity. Without deliberate effort to clean up and simplify, the system becomes progressively harder to change and less reliable.
It is an analogy rather than a literal application of thermodynamics. The second law describes isolated systems that cannot receive energy, and a business system is not isolated. That difference is the encouraging part: you can add energy through maintenance and reverse the drift, which you cannot do with a cooling cup of coffee.
They are a set of observations from Manny Lehman and Laszlo Belady about how real-world software changes. The two most relevant here are the law of continuing change, which says a system must keep adapting or it stops fitting its environment, and the law of increasing complexity, which says intricacy rises unless explicit work is done to reduce it.
McKinsey's survey of large-company CIOs estimated technical debt at 20 to 40 percent of the value of a company's entire technology estate, with 10 to 20 percent of new-product budgets diverted to servicing that debt. Stripe found developers spend roughly 42 percent of their week on maintenance and bad code rather than new work.
Treat maintenance as scheduled work, not spare-time work: reserve a fixed slice of every cycle for cleanup, refactoring, and updates. Keep the number of tools and integrations honest so there are fewer surfaces to decay, and fix small flaws as soon as you find them, before the complexity compounds on top of them.
Over 92% of the Western world's data sits on U.S.-owned servers, and the CLOUD Act lets authorities demand access regardless of location. Owning the stack is not ideological. It is jurisdictional, operational, and the difference between answering 'where is the data' with a street address or a vendor FAQ.
Eighty-eight percent of AI agent projects fail before reaching production. The gap between AI agents in production and agents that demo well is not a quality problem. It is a design problem rooted in compound failure math that most teams never calculate.
A technical SEO audit isn't a black box. It checks specific, measurable things — and most of the highest-impact fixes take less than a day.
Work With Us
Kief Studio builds, protects, automates, and supports full-stack systems for businesses up to $50M ARR.
Newsletter
Strategy, psychology, AI adoption, and the patterns that actually compound. No spam, easy to leave.
Subscribe
