Outstanding article. Treating tech debt like it's automatically bad drives a ton of bad decisions. Just like taking a mortgage on a house is a reasonable use of debt, there are reasonable uses of tech debt as well. People forget that refactoring is neither free in terms of resources nor free of risk. Is the cost of the debt worth the cost and risk of the refactor? That needs to be answered on a case-by-case basis, but the less-often a piece of code gets touched, the less concerned I am about tech debt. Does this mean I love tech debt? No, of course not. But it means I'm not going to apply black and white rules to it, it does not mean I'm going to go nuts over it, I'm going to evaluate it and decide if it makes sense to fix, and I'll coach the team to do better next time.

Because at the end of the day, the business isn't paying for "clean, elegant code", they are paying for "a working solution". Tech debt only is a concern to the people signing the checks if it stops the developers from doing work. And that's the real litmus test. "Does this stop us from doing work, or make it extremely hard to do work?" If not, what is the urgency here?

J.Ja