'Technical Debt' is a case where a specific thing was named before the general concept. Another case is the phrase 'mock object'. In the early 2000s, the original mock objects paper coined the term and defined them as testing stubs with builtin expectations. For years, people used the term "mock object" for any sort of stub.

Technical Debt is a very specific metaphor that Ward Cunningham framed as a strategy. Ever since, though, people have used the phrase for all sorts of entropy in software. If you look around the literature, you'll see people talking about type 1 and type 2 technical debt.

In my experience (and I'm the guy who wrote the Legacy Code book mentioned in the article), the typical entropy thing that we see in software has more to do with just taking the easy way and avoiding refactoring - different from Ward's concept.

That was my thought too. I guess OP was trying to distinguish between debt deliberately incurred vs wasted.

But maybe a better way to think about it is "leverage" vs "debt". Leverage is something you use to improve the product with a known and (hopefully) quantifiable return, whereas plain old debt represents those poor non-decisions.

Bad code with unit tests cannot easily be changed to "good code". Most unit tests of bad code are very brittle. Consider changing the permissions system in the article: All a typical rushed set of unit tests would do in this case is form a brittle specification.

In fact in my career I've never seen bad code + good tests unless the tests were added at a later date (typically by another developer trying to do what they can to stop code rot).

On the other hand it is a joy and straightforward to add unit tests to good code and typically they are much less brittle.