[kristianc]

Tech debt is a choice. Sometimes you'll want to embrace some level of technical debt in order to bring something into production quickly, with the understanding that you will fix later. It's part of a triad with Speed and Quality.

That may not be the choice Twitter has made in this instance, but it's a viable choice nonetheless. Defaulting to tech debt = evil wrong imo.

[dingaling]

The problem with technical debt versus financial debt is that the latter has a monthly mandatory cost ( interest payments ) that can't be ignored and which is visible all the way up to the C-level, whereas middle-management can keep obscuring the presence of technical debt and pushing its repayment out to the right.

Essentially it's a 'free' internal debt, regardless of how often architects and developers complain of its cost.

Thus in a contest between doing something right, but expensively, versus good-enough-for-now but technically-constrained the latter will usually win.

[tomblomfield]

It's not "free", it's just much harder to measure.

The cost is reduced development velocity, and perhaps reduced systems stability.

[lostcolony]

Which developers get blamed for, even though it was a managerial decision to take on the debt.

Financial debt has clear cost; technical debt doesn't. So it seems 'free' to the non-technical.

[cel1ne]

And sometime a workaround is the best solution you'll get. Because solving the problem properly might introduce new issues, which might require new workarounds.

[paulddraper]

Exactly. The operative part of "workaround" is "work".

[rhizome]

Sometimes it seems like "technical debt" is used as a dysphemism for "refactorable." We see railing against technical debt, then tomorrow there's a "code is never finished" post that gets nods all around. A bit of a strawman, but my point is that there's a big picture of the technology lifecycle that somehow fosters disparate contexts for the same exact thing.