[gHeadphone]

You make a god point about the generally accepted meanings for terms for technical debt. However, there are lots of companies ive worked in (and more I know of) that try to scientifically calculate a numerical value for Technical Debt. At best, it's a metaphor, a mental aid to understand a loose concept. Any attempt to calculate implies that there is some 'best solution' that should be achieved. However, this almost never exists, any best solution is in the eye of the beholder, it will differ depending on whether you are a developer, DevOps, client, manager, CISO, barista, best friend, pet.........

[dgb23]

That’s because abstraction enables a mental model and a language around the translation of your domain to computation.

When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression.

In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are multiple ways of expressing the same.

Quantification of unnecessary complexity can only be done after you know what is necessary and how you express that.

[jjk166]

While there may not be some universal best solution, that does not mean all solutions are created equal. You can certainly look at two options and say "this one will take about half as much effort to fix later" or "it'll take as much time, but we can put a less skilled person on it." Maybe putting a number on it doesn't mean anything in absolute terms, but it's still useful in relative terms.