I ran across an interesting concept in my reading today: technical debt, and its cousin design debt. The concept is basically the application of the Second Law of Thermodynamics to software development. As you develop software, you affect the entropy of the code. Feature development typically increases entropy, while refactoring and explicit design activities decrease entropy.
Why do we care about entropy in software code? Code with high entropy is harder to maintain, harder to fix bugs in, and harder to add features to. It basically increases the cost and time to get new releases of the software out.
The concept of design debt argues that this kind of entropy is additive across releases, and that each time you perform entropy positive actions you increase the amount of work needed to dig out and make the code maintainable again.
I’ve lived this, for sure, and I suspect most others have too. But what makes it really interesting is thinking about it dynamically, where it is made clear that design debt decreases the profitability of a project. I think it’s even worse than it appears in the diagram, because the diagram neglects the time dimension. As the cost of development increases, more than likely the time to develop also increases—which means that Domain Evolution proceeds even farther while you are trying to catch up. This means that you have to increase the number of features even more, but that incurs a higher design debt still. It’s an unpleasant positive feedback loop.