Nicely done. Good to see an engineering blog acknowledging tech debt openly. I'm with you all the way until the last paragraph which short-changed the conversa

Nicely done. Good to see an engineering blog acknowledging tech debt openly. I'm with you all the way until the last paragraph which short-changed the conversation a bit. Quoting a few lines to respond below: >> Build things to be easy to throw away and replace; it’ll make your code more modular. One valid strategy to manage debt is to declare bankruptcy or amnesty on debt – that is throw away the code (because this code is no longer needed). In domains where this possible, definitely use it. But in most real-world touching software domains this is not likely possible. >> Good tech debt has clear, well-known limitations. Document these in code comments, READMEs, FAQs, and conversations with the people who’d care. Doing tech debt accounting in a more formal manner is required to intentionally take debt. In the locking example, it is a design debt (not just a code debt). If the debt isn't document well and then it can become a ticking time bomb to be tripped by a clueless developer later.