Software Entropy Is Real

Almost every project I've been on has gotten worse over time. Not better. Worse. Which is interesting, because maybe I'm the problem? Or maybe this is just the natural lifecycle of software - projects trend toward technical decay, then someone does a sweeping rewrite or major refactor to "catch it up," and then it slides back into the abyss again.

Turns out there's a name for this: software entropy. It's not just my experience or bad luck. It's thermodynamics applied to code. Manny Lehman described it back in 1974, and "The Pragmatic Programmer" dedicated a whole section to it using the Broken Windows Theory as a metaphor. As software is modified, its disorder naturally increases unless you actively spend energy fighting it.

Here's the kicker: we've stopped fighting it. Somewhere along the way, we collectively decided that entropy isn't something to combat - it's just how software is. Code rots. Systems decay. That's normal. And that acceptance is killing our codebases.

How "Just Ship It" Became Standard Operating Procedure

You start with a clean architecture, clear boundaries, good intentions. Then requirements change. Deadlines hit. Someone needs a feature shipped now, and "we'll fix it later." Except we never fix it later. We fix it again later, with another quick fix. And then we fix that fix with another one. Now you've got patches on patches on patches, and nobody knows what any of it does anymore.

"Just ship it" has destroyed more systems than it has helped. Not because shipping fast is inherently bad, but because we've lost the awareness of what we're doing when we ship. Every shortcut, every "good enough for now," every skipped test is a conscious choice to accept entropy. But we've stopped treating it like a choice. We've made it the default.

Robert C. Martin talks about this in Clean Architecture - if you build a system that's impossible to change, you've built a bad system. And you know what makes systems impossible to change? Years of "just ship it" decisions compounding on each other until the codebase is so fragile that changing one thing breaks three other things you didn't even know existed.

The Nuance Nobody Talks About

Here's where this gets tricky: sometimes you DO need to just ship it. Sometimes the right business decision is to take on technical debt to hit a deadline, test a hypothesis, or capitalize on an opportunity. I'm not arguing for perfectionism or analysis paralysis. Speed has value.

The problem isn't shipping fast. The problem is shipping blind. It's the difference between consciously taking on technical debt with a plan to address it, and unconsciously accumulating entropy because "that's just how we work here." One is a strategic decision. The other is how codebases die.

When you merge that PR with the shortcuts, do you know you're taking on debt? Have you documented what needs to be fixed? Is there a ticket to come back to it? Or are you just hoping nobody notices and it'll be fine? That difference - between conscious and unconscious technical debt - is everything.

Everyone Loses When Entropy Wins

Here's what kills me about normalized entropy: everyone loses. Your customers lose because they're getting a degraded experience. Features break. Performance degrades. That bug that "only happens sometimes" happens more and more. Your engineers lose because working in the codebase becomes agony. You spend more time navigating around landmines than actually building. Every change is a gamble. Every deploy is a prayer.

Your executives lose because that "simple feature" now takes three months to implement instead of three days. They don't understand why everything is so slow, why every estimate is so high, why the team that used to move fast is now moving through molasses. It's a lose-lose-lose. And it started with small, unconscious decisions to let things slide.

PRs Are Where We Choose

You know that moment when you open a PR and you know it's not quite right? There's that shortcut you took, that edge case you didn't handle, that test you skipped because "we'll add it later." And then you hit submit anyway. Here's the kicker: it gets approved in 14 minutes with a "LGTM 👍" and a ship-it emoji.

This is where we're choosing entropy over maintenance. PR reviews have become a formality, a checkbox to tick, not an actual checkpoint where we decide if we're being intentional about technical debt. And that's the problem - we've stopped using reviews as a tool to maintain awareness.

Here's a take that'll probably piss people off: I want my PRs to be blocked. Hack them up. Question everything. Tell me that function name sucks. Point out that I'm handling errors poorly. Show me the edge case I missed. Make me justify why I did it this way instead of that way. And if I'm taking on technical debt, make me articulate why and what the plan is to address it.

If you approve my PR in 5 minutes, you didn't review it. You glanced at it, saw my name, and decided it was probably fine. And you know what? It probably is fine. But "probably fine" is how entropy becomes the default. Reviews are supposed to be the checkpoint where we stay conscious about our choices.

The Tools We're Ignoring

Here's the thing that baffles me in 2025: we have AI that can review code, and we're barely using it. I'm not saying AI should replace human review. But why aren't we using it to prime the human review? Let AI catch the obvious stuff - the missing error handling, the potential null references, the performance footguns, the security vulnerabilities. Then let the human reviewer focus on the hard stuff like whether this change is consciously taking on debt, whether the architecture makes sense, whether the approach aligns with where the system needs to go.

We're letting PRs through with comments like "looks good to me" when there are literally tools that could point out five things wrong with it in seconds. Tools that could help us maintain awareness instead of slipping into unconscious entropy.

Choose Awareness Over Entropy

You have a choice with every PR, every feature, every "quick fix": stay aware of what you're doing, or slip into entropy. There's no middle ground. Every time you let something slide without acknowledging it, you're choosing unconscious technical debt. Every "we'll clean this up later" without a plan to actually do it, every "this is good enough for now" without understanding the tradeoffs - you're choosing entropy.

Standards mean PRs are hard. Your code gets put under a microscope. You have to justify your decisions. If you're taking on technical debt, you have to say so explicitly and explain the plan. You might have to go back and rewrite things. And you know what? That's exactly how it should be. Because the alternative is codebases that slowly become impossible to change, and everyone loses.

The Fix Is Intentionality

Don't settle for unconscious entropy. Don't accept "that's just how software is." Fight for awareness at every step. If a PR is taking on technical debt, make that explicit. Document it. Create the ticket to address it. Make it a conscious choice, not a side effect.

Yeah, it'll feel like friction. Yeah, people will push back. But here's what I've learned after years of watching projects decay: the time you "save" by shipping blind, you pay back ten-fold later when you're trying to change a system that's become impossible to change. The choice isn't between moving fast and moving slow. It's between moving fast with awareness, or moving fast into a codebase you'll eventually need to rewrite.

Software entropy is real. It's not going away. But we don't have to accept it as the default. We can fight it with conscious decisions, rigorous reviews, and the simple act of staying aware of what we're building and why.

---

What's your experience with software entropy? Do you think conscious technical debt is realistic, or am I being too idealistic? I want to hear your thoughts - especially if you disagree.