Programming

Technical debt is a management term.

The reason we use it is to tell non-technical management people why implementing a simple feature might take an hour on a fresh project and a week on an old legacy project.

It's used to tell them why we shouldn't go with the quickest and dirtiest solution but instead should go with a more expensive proper solution.

It also tells management why we might have to spend some time imrpoving our code base without any tangible improvements to the customer.

And because it's a term that speaks to non-technical management it uses financial language, becausee that's what they understand. Technical debt means "I am choosing to cut corners today, but we will have to pay up in the future by fixing stuff that wouldn't be broken if we do it right today."

And because it's aimed towards non-technical management and not towards developers, it's of course not very specific. Non-technical management doesn't need to understand about dependency hell, unclean code or bad developer documentation. That's not their field and it doesn't have to be.

The real problem in OOPs example wasn't that there's no clear metric or definition of technical debt. The problem was that non-technical managemnt thought that technical debt is an engineering concept instead of a management one, and thought that they themselves were allowed to meddle with it.

The right way to handle that is to ask the people who are actually impacted by technical debt what they want to improve. Any developer can quickly give you a good list of the most pressing tech debt issues in their code base. No need to pull in someone from outside of the project to make up some useless KPIs that will end up missing critical topics.

Btw, engineers already have engineering terms for what's described as technical debt. E.g. "dependency hell", "low test coverage", "outdated dependency", "bad code style", "unoptimized code" and so on. And since these are engineering terms, they actually have specific meanings and most of them are testable and quantifiable in some specific way.