This is a fairly technical analysis, and the terminology used in many cases is above what I know about networking. But the one quote that will stick is this.
"There is no such a thing as a temporary change or workaround: In most cases, workarounds are tech debt."
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.
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.
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.
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.
Truth. The only time I consider something temporary is when the business stakeholder asking for the temporary change has a) promised b) a specific period c) when the cleanup happens, and d) they have a track record of honoring their promises.
And I encourage everybody to make that their standard. Now I never cut a corner without that. I never even offer. My default is a zero-additional-tech-debt approach, because that's the only thing I think is responsible or sustainable. If there's a legitimate business need for taking on a bit of tech debt, I will propose the deal of splitting the work into, say, "experiment" and "cleanup", but cleanup ends up in the workstream with a date attached. If the stakeholder accepts the deal but fails to honor it, I revoke their tech-debt credit card.
No, it makes much more sense than that, since there are changes that are not incurring technical debt. It's only "temporary changes" and "workarounds" in other words quick kludges that the say are incurring permanent technical debt.
"There is no such a thing as a temporary change or workaround: In most cases, workarounds are tech debt."