The top comment currently says "This sounds like nonsense to me", its first child agrees and add something like "everybody new it since ages". Well, for one I

The top comment currently says "This sounds like nonsense to me", its first child agrees and add something like "everybody new it since ages". Well, for one I like this article. I wonder if we developers could use entropy instead of debt to explain the necessity of refactorings and abstractions. When you say that there is a lot of technical debt, the boss would assume that it is like financial debt: as long as you are still running forward, you can go to the banks and fix the issue with them. It is reversible. But technical "debt" is not reversible. One wrong lazy "if customer = John Doe" (instead of a proper configurable flag) paves the way to other wrong ifs, and it becomes very fast an irrecuperable mess. This is more like growing system's entropy: a broken mirror won't reassemble, or spilled water won't come back to the bowl, as the Chinese say (for a lost hymen). Using entropy instead of debt, provided people understand the concept#, we could by showing that increasing the complexity of a system the wrong way (adding ifs because "no time") is drastically and irreversibly reducing the number of possible futures. # Obviously the weakness of my point...