This is a blog about the decay of software – and how to prevent it. Wikipedia has a detailed explanation of entropy. In short, in can be summarized as
- Entropy is a measurement of the degree of disorder in a system. Higher entropy means less order.
- When two systems of different entropy adjust to each other, the total amount of entropy increases.
What does that have to do with software? There are some striking similarities:
- The decay of software is an inherent process. Requirements change during implementation, features get added that don’t quite fit the original architecture, “quick and dirty” fixes are introduced, and people are following different coding philosophies.
- If left alone things will get worse. It requires energy in the form of reviews, redesign, and refactoring to fight the decay.
- If the environment does not provide rules and guidance, the software will adapt to this low standard.
The next question: if it requires effort (money, time, resources) to fight entropy, why should you pursue this goal? If you are or have been programming you already know the answer. If not: you gain software quality in the sense that code becomes more robust, readable, maintainable, extensible, flexible, reliable, and – gasp – more enjoyable.
Keep in mind the initial implementation of software is just one of many cost factors. The operation of unstable systems, fixing bugs during production, difficult addition of features to the software adds substantially to the total cost of a system over its lifetime.
This is why fighting software entropy is important.