Technical debt

Technical debt does not mean poorly written code or outdated libraries that you need to eventually update.

The debt metaphor in software development likens technical debt to financial debt: taking shortcuts in code to release a product quickly, with the understanding that you’ll later “pay back” this debt by refactoring the code as new insights emerge.

In other words, it means taking shortcuts to release software quickly, with a commitment to refactoring later as understanding deepens. This is like taking out a loan and repaying it with interest, which is acceptable if done mindfully.

In contrast, the common misunderstanding of technical debt often focuses on the negative consequences: poor code quality that accumulates over time if not addressed, leading to slower development and maintenance. It’s typically seen as something to be minimized rather than a strategic choice, while the original metaphor views it as a conscious trade-off when building and refining software.

The key difference is that taking on technical debt can be a strategic, temporary decision for learning, as long as the intention to address it later remains clear.

The debt metaphor in software development was coined by Ward Cunningham.