In general, I'd agree with that assessment, but the debt-based metaphor also reaches its limits in a couple of cases. One of which is that it is often really h

In general, I'd agree with that assessment, but the debt-based metaphor also reaches its limits in a couple of cases. One of which is that it is often really hard to quantify, but that does not seem to stop many non-technical manager types from trying to treat it like financial debt nontheless. Another one is that unlike financial debt, which should be controlled by various organization-internal mechanisms, tech debt is often not something management is conscious about (at least when it is "created"). I've seen far too many examples of horrible code that can simply be explained with lazyness or incompetence, but I'm pretty sure management never called for a hard to use, unnecessarily complicated API. Also, if the tech debt is caused by management, it is usually an implicit byproduct of unrealistic time constraints, and I'm pretty sure in those cases they would often choose find another solution too if they were conscious about how bad the problem they're creating really is. Edit: Either that, or their incentives are way off because they don't have to deal with the consequences. Which is also the real cause why financial debt is usually strictly controlled.