"Technical Debt" is a problem whatever we call it. It is a worse problem than real financial debt because financial debt is easy to measure in dollars whereas t

"Technical Debt" is a problem whatever we call it. It is a worse problem than real financial debt because financial debt is easy to measure in dollars whereas technical debt is not. There is no reasonable way for measuring technical debt I've seen. The amount of technical debt is difficult if not impossible to quantify yet it is intuitively clear it is an issue. You add code to your code-base making it do more and at the same time making it less optimal in how the code is organized. At the same time you know you perhaps should spend time and effort to re-organize it, but how much? How often. Maybe you have a rule of thumb but who's to say that rule is "correct". Trying to lessen the amount of technical debt happens by what is called "refactoring". While it is clear that at some point we better do some of that, the unanswered question, and the reason why "technical debt" is a problem, is how much and how often should we refactor. I haven't seen any clear guidelines for that. Are there?