
Technical debt is not poorly written code.
The technical debt metaphor only applies when there is a conscious and strategic decision.
A short thread with examples


Example 
You write code to reflect your *current* understanding of the problem.
You incur debt when this understanding is *partial* and, even then, you deliver the software (to learn more).
But you must pay the debt: you must incorporate the new learnings into the software.

You write code to reflect your *current* understanding of the problem.
You incur debt when this understanding is *partial* and, even then, you deliver the software (to learn more).
But you must pay the debt: you must incorporate the new learnings into the software.
Example 
You must meet a tight deadline to get the economic resources needed for a subsequent deadline.
Then, you make the strategic decision to write a suboptimal design for the first deadline.
After that, you pay the debt and improve the design for the second deadline.

You must meet a tight deadline to get the economic resources needed for a subsequent deadline.
Then, you make the strategic decision to write a suboptimal design for the first deadline.
After that, you pay the debt and improve the design for the second deadline.
The key is that debt *must* be paid.
And your ability to pay it depends on how clean the code is (because you need to refactor).
Clean code is a prerequisite for technical debt.
An overly coupled unmaintainable codebase is not technical debt. It is just a mess.
And your ability to pay it depends on how clean the code is (because you need to refactor).

