> If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”.

It's really surprising how often the “quick” approach turns out to be slower than the “right” approach.

Now sure, there's such a thing as focusing too much on non-market relevant aspects of a project, or going down rabbit holes, or designing and coding for a future that will almost certainly never come, but it still continues to surprise me how often when the choice is between "quick" or "right", that "quick" actually turns surprisingly soon into slow.

There's a saying apparently in use in the military "slow is smooth, smooth is fast". That's the kind of wisdom we need to aim for in software engineering. "More haste, less speed".

Oh yeah, the other difference is that there's no external force that will take you to court if you don't pay down technical debt, so in fact most organisations are terrible at paying it down. If you don't literally have a plan on the calendar with names and dates committed to improve the code, you're most likely fooling yourself by calling it technical debt. The true metaphor is much closer to 'Superfund site'.