[firebaze]

Quite often "technical debt" from an engineer perspective is an asset from the leadership perspective. Make of it what you want, but code which is bad from a customer perspective usually doesn't live until it's legacy.

And sometimes the technical debt cloud disappears after fully understanding the business rules and special cases which were the root cause for the code in question. This often gets overlooked and may (edit) lead to refactoring/rewrite approaches which ultimately fail. As everyone knows, not a rare occurrence.

[jcims]

We need a different word. ‘Technical debt’ implies some kind of objectively quantitative zero sum game, when it is anything but.

[int0x2e]

There are a couple of amazing talks by Dan North, where one of the ideas he shares is that the entire idea of technical debt is wrong - it implies that "good" code a team produced is an asset and "bad" code is debt, and applies a set of moral judgements where teams that produce this debt are bad. Instead - code is neither an asset or debt - it's just cost. It merely is a direct result of whatever effort the team has spent in the past, but at any moment it could be greatly simplified or even replaced by a new open source library or commercial tool. If good code was an asset, replacing it with something would be rare, but history shows us we keep replacing libraries and entire products despite some of them being made up of really great code.

[hitekker]

> All code is a cost

This is the truth, as far I'm concerned. We say "technical debt" instead of "bad code" because the former sounds more acceptable in the business environment. But it's still the same meaning, code we don't like, and code we don't.

[RNCTX]

> We need a different word. ‘Technical debt’ implies some kind of objectively quantitative zero sum game, when it is anything but.

Not only that, but it's been around long enough that bad management types throw the term around. That's a sure enough sign that whatever usefulness it had has been far outlived.