Technical Debt is an interesting phrase. We all have a sense of what it is instinctively, but we rarely want to think about it. If we think about it too hard, we feel somewhat oppressed by entropy. All systems tend to toward disorder and software systems are no different. The big question that we all face is what to do about it.
Systems tends toward disorder. Disorder is hard to reason about and risky to deal with, i.e. you’re likely to avoid dealing with it at all. But, most successful products have a system with more technical debt than you’d like at its center.
Increasingly, I think that the only way to confront technical debt and complexity is to contain it. Languages and tools only seem to help at the margin. Rigorously splitting large, complex, debt-filled systems into smaller, proportionally complex and debt-filled systems is the way to gain traction.
You can’t solve technical debt or essential complexity; you can only hope to contain it.
