I’m not sure where, but I read a pretty insightful comment some days ago that stuck with me, as I reflect on why software systems tend toward chaos. The author, a presumably experienced programmer, said something along the lines of:
“I used to enjoy refactoring code that I found ‘ugly’ because it didn’t follow modern practices or lacked generality. I often wondered why no one had already made these improvements. However, I later realized that the ease of making changes was a sign of good code. My proposed alterations would likely only complicate it. The danger lies in the fact that good code is inherently malleable, and frequent modifications can eventually render it difficult to maintain.”
I think there are many, many more forces at play than just this one that help to explain Software Entropy, or the idea that software tends towards chaos, which results in countless hours of misery for developers and end users alike. But there was something so obvious the author distilled, that it was almost beautiful. Like of course a codebase would get worse over time, with factors like this!
It reminds me of other ideas, like the Peter Principle, which is the idea that “people are promoted to the level of their incompetence.” Which is itself highly related to “The Bozo Effect”: the idea that a firm’s employees will trend downward over time as standards go down and an overconfident middle management class takes over. Sometimes they say spiraling down so badly and quickly it’s referred to as a Bozo explosion. Or just the general idea of enshittification.
Systems can work for or against us, and in all these cases, as hyperbolic or haughty as the theories may sound… perhaps there’s some truth to it. I certainly believe it when it comes to code!
Anyways, it’s something to keep in mind the next time we want to “clean up” that class or function. Then again, if we don’t refactor, we’ll surely end up in Codebase Hell too. My oh my, what a tightrope it can be.