[bxparks]

I don't think it's "learned helplessness". It is a rational, calculated tradeoff decision. In many situations, it is more painful to fix the underlying layers of technical debt, and more time consuming to fight the push back from the various teams that own different parts of the technical stack. It's far easier to just silence the pagers while on pager duty for that week.

It's also caused by misaligned incentives. At most BigCo, people don't get promoted for fixing technical debt. They get promoted for launching shiny new features and products.

[hinkley]

Technical debt is all of the forms of self-sabotage that don't have clear metrics associated with them.

If they had clear, unimpeachable metrics, then you could increase your status by fixing them. Since they don't, few people engage with them. Worse, engaging with some of these problems can lose you status, and so tackling them becomes a form of self-sacrifice.

[WalterSear]

Hinkleys's law: A measure that becomes a target might cease to be a good measure, but a target that isn't measured ceases to be a target at all.

[kubanczyk]

Does this law apply also to projects like Linux Kernel or Wikipedia? If not, where does it apply?

[lumost]

A thousand times this. Good, steady software ownership is generally not what leadership wants.

Big new features are, it’s infinitely easier to build process improvements into new projects vs fighting for improvements in existing areas.

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

[nyulmalac]

Oh this hits close to home. At my BigCo I have seen tremendous amount of great tools/product landed in the trash bin, because it was only interesting until somebody get the promotion… Immense amount technical dept and lack of viable business model lead to fast death of great ideas… What a huge waste…