"Tech debt" was coined as a metaphor to be used when talking to non-tech leaders, to explain why investment was needed into systems to keep them running, and not just focus on new shiny features to drive sales.

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.

I don't find this article very helpful. The first paragraphs promises to summarize various claims the author has heard about tech debt. The second bit is a list of theses that are not very helpful, and come across with a bad attitude. Then the whole thing ends without substantiating the claims made earlier.

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".

“Technical debt” seems like an objective description of a real thing. Complex software systems that actually get used and adapt to requirements over time inevitably accumulate cruft, bugs, less than ideal design and implementation in hindsight. That’s in the nature of software development, a feature rather than a bug.

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.

Wrong link. The proper link is

https://mooreniemi.github.io/2022/03/19/tech-debt-isnt-real-...

Yes.