[tristor]

I think the metaphor for technical debt is leaky, but I don't think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to "rushing things", but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I've seen technical debt addressed successfully in a fairly long (~18 years) career:

1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.

2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.