So the article is right - it isn't real. But also wrong in that the need for that metaphor is very real. If defining tech debt leads to uncertainly, I recommend skipping definitions and just focus on the purpose - to use the concept as a framework to help leadership and engineering find the right balance between new feature development and internal system improvements.
The helpful part boils down to "test coverage increases your confidence in your system". Also interesting is the connection between lack of PMF and what you could call "flailing-oriented development".
When programmers talk about “technical debt” they actually mean to communicate their boredom, disdain, impatience, fear of working with legacy code they didn’t write. They imagine how they might do it better now and judge the legacy system in that light. Programmers strongly prefer creating something new, and that bias leads to judging code that works by its flaws and shortcomings, magnifying them and calling them “technical debt,” giving the liabilities 10x more weight than the business value.
https://mooreniemi.github.io/2022/03/19/tech-debt-isnt-real-...
