Software Entropy


  • Physics: A thermodynamic quantity representing the unavailability of
     a system’s thermal energy for conversion into mechanical work,
     often interpreted as the degree of disorder or randomness
     in the system.
  • Lack of order or predictability;
     gradual decline into disorder

The first definition has some relevance, but what we are really interested in here as engineers is the second definition.

Lack of order or predictability; gradual decline into disorder

Sound familiar?

If you’ve ever been lucky enough to be part of a greenfield software project, then you know exactly what this means, and you’ve seen it in action. There’s nothing like starting that shiny new project. That nice, clean directory. The addition of each and every file meticulously thought out and vetted. Every line of code carefully pored over by teammates. Formatting is pristine, just the way you like it, or perfectly according to ‘best practices’ from the start. Let’s not forget the immaculate 100% test coverage and book-complete documentation. Total perfection in every way.

Now, let’s take a step back and talk about entropy, and how it’s normally described in layman’s terms. On a more macroscopic scale, universally so to speak, entropy is basically the reason we perceive what we think of as ‘time’. Why does time only go forward and not backward? Entropy. Think about it, once you scramble an egg, you can’t ‘unscramble’ it and put it back in its shell. Once you’ve added the cream to the coffee, you can’t separate it out back into its container. Time moves forward, ‘things’ get more and more disordered. This is what happens to most software projects and it’s what I mean by the term, ‘software entropy’.

Just to clear things up a bit, I know some of you might be thinking…yeah that sounds a lot like complexity. In some ways yes, but complexity is more of something that gets injected into a project by design, whether good or bad intentioned. And yes I know any single developer can add complexity just by the code she writes, but that’s not what I’m talking about here. I’m talking about the gradual decline in the quality of the codebase/project.

So back to our perfect little software project. Of course, everything starts out nice and neat and perfect. But what happens over time?

In my opinion, the biggest contributor to software entropy is deadlines. Yes yes, I know, deadlines are necessary and I agree completely. Without deadlines in the business world, us engineers would probably never stop tweaking and enhancing and building. We’ve gotta have a hard stop, I get it.

But let’s think about it for a minute and analyze why deadlines are the main culprit for gradually degrading software over time.

As with most projects, not just software, when starting out, time seems to be an abundant resource, almost perceived as limitless. If there is any type of learning curve for the engineers involved, such as learning new technologies, or methodologies, then initially the progress of the project moves along at a slower pace while the engineers involved get there feet under them and start to develop a pace. All the while, there is a deadline looming, and moving closer every day.

So the project moves along, built meticulously from the ground up and starts out perfectly, as described above. But as that deadline looms, schedules tighten up, shortcuts start to be taken, documentation is viewed as not immediately necessary, etc…you get the picture.

After a while, no one is really paying attention anymore to perfect test coverage, pristine formatting, unnecessary unused code, commented out code, code smells that shouldn’t have been added in the first place. These are all things that build up gradually over time and never really get corrected, removed, or cleaned up because the test-suite still passes, the code still works, and you’ve got a deadline to meet.

So how can we combat this insidious entropic decay?

The best way I know how is to just be vigilant of it at all times. Make sure your team is aware. Be on the same page. Conduct thorough code reviews and pay special attention to the little things. I know it’s not always easy, and I’ve been part of both sides. Deadlines often reign supreme and we just have to do the best we can as engineers. But at least being aware of any pitfalls such as this can mitigate the nasty effects of software entropy.

That’s it brothers and sisters, thanks for reading \,,/

Originally published at