It's down, so: https://web.archive.org/web/20200930101416/http://wiki.c2.com/?WardExplainsDebtMetaphor https://web.archive.org/web/20200930101416/http://wiki.c2

It's down, so: https://web.archive.org/web/20200930101416/http://wiki.c2.com/?WardExplainsDebtMetaphor https://web.archive.org/web/20200930101416/http://wiki.c2.co... There, the original metaphor is exactly what the OP refers to: > if we failed to make our program align with what we then understood This wouldn't be even considered tech debt in many projects today. It is code that has been well done, according to all project's standards except just for one point: it only partially incorporates our current understanding of the problem domain. When some enlightenment moment happens in a project, the contributors are usually split: - some either understand the new idea or want to understand it, - some shrug it off or even explicitly reject it. Cleaning up this kind of debt will harm the work of the latter for a time. So it's decidedly a different decision than refactoring an obvious big-ball-o-mud (the code which is not properly mapping anyone's ideas). The discussions can be heated, and so naming/popularizing the idea is beneficial.