What is Technical Debt?
Sep 23 2016
Ward Cunningham is credited with coming up with the debt metaphor. This is the same “technical debt” metaphor that is so often associated with poorly written code.
It seems that the idea that Ward was trying to convey is that software can be delivered more quickly, but it will be at the expense of the understanding of the application. This is understanding that would be used to build and design the system. Repayment of this debt is the energy put forth on to refactor and reflect new learnings of the application. The consequence of not paying back this debt is a decrease in velocity.
What Ward is not talking about about was writing sloppy code. He even clarifies his stance on the metaphor shouldn’t be used as an excuse for poorly written software.
Before coming across this original meaning of the debt metaphor, I took technical debt to describe any decisions made in the past that are causing pain today. This might have included sloppy code, or a lack of tests.
Even with this new insight, it is difficult for me to say that sloppy code or a lack of tests lives outside of the realm of the metaphor. I suppose the reason for this quibble is that they have the same effect on the velocity of development, albeit perhaps at at an increased interest rate. It fits right in with the metaphor.
On other hand, is there ever an excuse for sloppy code, and if so, should it exist inside a piece of software that is worthy of the debt metaphor?