Have you noticed life gets more complicated the longer it goes on? Entropy in software engineering (and life, for that matter) means no matter how much you organise around you, your day, your work, your family, your hair, you end up with less peace and more disruption. You tidy the desk on Monday. By Wednesday it looks like a crime scene. You refactor the codebase in Q1. By Q3 it's spaghetti again.

That's not bad luck. That's entropy.

What Even Is Entropy?

Entropy is there, around you, constantly. You can't see it, but you can feel it. The sweat through your pores on a humid day. The frizz in your hair when it rains. Your order of Lamb Rogan Josh not making it on time because three other things went wrong between the kitchen and your front door.

At its core, entropy is a measure of disorder in a system. Simple definition. Not simple to deal with. The second law of thermodynamics tells us that in any closed system, entropy either increases or stays the same. It never decreases on its own.

Everything tends towards disorder, no matter what you do.

In a way, creating order actually creates more disorder somewhere else. Want proof? Make your 8 year old clean his room. Sit back. Give it 48 hours. That room will look like a hurricane passed through, and somehow there'll be Lego in rooms the kid hasn't even been in.

That's entropy.

The Slow Unravelling

Whenever anyone tries to create order, entropy immediately begins to take it apart. This applies to everything. A newly manufactured stick of gum. A freshly deployed microservice. A 100-story skyscraper. The moment it's "done," the clock starts ticking.

Your brand new car starts depreciating the second you drive it off the lot. Your freshly painted wall starts fading the moment the last coat dries. The deploy you pushed at 5pm on Friday? Something in the dependency chain shifted overnight.

Entropy doesn't care about your plans. It doesn't care about your sprint velocity or your Jira board. It's just physics doing what physics does.

So What's This Got to Do With Engineering?

Everything.

That line of code running on a cloud VM that fails after six months of working fine? Entropy. The underlying OS patched, a certificate rotated, a dependency bumped a minor version that wasn't actually minor. The environment changed around your code while your code stayed still.

The data stored on disk that silently corrupts a block? Entropy. The heap that grows and grows until the garbage collector is spending more time cleaning up than your application spends doing useful work? Entropy.

But it goes beyond the technical. The dependencies across teams that worked fine when there were four teams and now there are twelve? Entropy. The tech debt that accumulates no matter how many "tech debt sprints" you schedule? Entropy. The architecture decisions that made perfect sense two years ago and now feel like wearing shoes three sizes too small? You guessed it.

Software systems are entropy machines. They start ordered, they tend towards disorder, and the energy required to maintain order grows over time. Every feature added, every integration connected, every team onboarded increases the surface area for entropy to do its thing.

The question isn't whether your system will decay. It will. The question is what you do about it.

Coming soon: Engineering and Entropy, Part 2: how entropy actually manifests in codebases, infrastructure, and teams. And more importantly, what we can do to slow it down (because stopping it isn't an option).

In the meantime, if you're interested in how organisations accidentally reward the wrong behaviours (which accelerates entropy, funnily enough), check out war heroes vs the meticulous engineer. And if the concept of small decisions adding up to big problems resonates, there's the tyranny of small decisions in the age of agents.