The Technical Debt metaphor is a Mental Model describing the accumulative effect of clutter in a system, normally intended as a warning that trade-offs exist between short-term and long-term goals.
Clutter, or cruft, forms in a system by making deliberate or unintended now/later choices in the name of expediency - such as leaving corner cases unimplemented or in an error state, prioritising the delivery of a fix over writing a successful passing test, shipping a sub-optimal code structure now and deciding to fix it later.
The overall result is instability through unpredictability - in the ability to change code without incurring negative side-effects, or being able to effectively reason about those consequences. Development and delivery slows down as maintenance costs increase.
Technical Debt is an instance where A poor metaphor dilutes the mental model, because debt is also a positive enabling factor.
For instance, the concept of Technical Debt is normally used to describe the negative accumulative consequences of code clutter if unpaid, but often interpretations forget the positive, enabling factor that debt can have that can also factor into the overall decision-making framework on whether to take on debt.
For instance, the assumptions may be invalid (we Learn along the way) and baking these in incurs a high cost to change later, in the form of Technical Debt
This is a demonstration of how the accrual of Technical Debt slows down delivery.
Short-term feature factory model for products, which can accrue Technical Debt as priority is on delivery not maintenance
Technical Debt is a metaphor describing the gradual decreasing ability to develop, and decreasing rate of delivery, of quality software.
Unit tests provide the path to production in the form of a quality gate - therefore if tests hinder getting changes to production, through being ridden with communicating the intent of the code, then the ability of the developer to deliver to production is compromised (Speed is a byproduct of quality)