Simplest kind of technical debt: 1. I use a particular technique/abstraction/whatever to solve the problem, it solves the problem well. 2. Over time we solve

Simplest kind of technical debt: 1. I use a particular technique/abstraction/whatever to solve the problem, it solves the problem well. 2. Over time we solve other problems elsewhere. As we go, the bigger picture becomes clearer and we pick more suitable techniques/abstractions/whatevers as we go. 3. Eventually we have to solve a problem that interacts with the original problem, the newer techniques/abstractions/whatevers don't work cleanly with the new ones. So we have to make a choice: a) Hack something together that solves the current problem without us having to touch much of the older code. b) Rewrite the old code to match the newer technique/abstractions/whatevers. c) Put down tools and thoroughly evaluate whether there's an even better technique/abstraction/whatever that solves the old problems and the new ones. We all know that C would give us the best code, but it's also likely to mean we never get anything done because every new problem means reevaluating everything. B happens more often, but in reality we usually end up doing A due to various pressures. At no point has bad code been written, but there's technical debt nonetheless. Over time we become better at adopting patterns an architectures that allow for clearly defined boundaries and reduced cost of making mistakes, you still get technical debt (because just about anything you want to change can be considered technical debt), but it doesn't tend to cripple your ability to get things done.