Debt Metaphor is not Technical Debt

Ward Cunningham's coined phrase "the debt metaphor" has caused some confusion. I've seen it mis phrased as "technical debt." This is a mistake because if you watch the linked video, you'll see that Ward is talking about your understanding of the features and the model, and not about going into debt by taking programming short cuts.

Let's take a look at how Extreme Programming does design. Kent Beck expresses the XP practices as taking the good things about development and turning the knob to eleven. This includes design. If design is good, don't relegate it to a phase of development then end that phase and start construction, i.e. big design upfront (BDUF). Do it all the time and allow the design to emerge. This is where the terms emergent design and evolutionary design began.

But if you are going to start writing code on day one, and only do enough design to complete the current story, then you are writing code with a smaller understanding of the problem than you would had you done BDUF. So you are going into design debt in order to allow the design to emerge. As your understanding grows, you can refactor the code to better reflect your new understanding. That's paying off the debt. For that to work, the code needs to be as clean as possible.

I see blogs and email posts talking about technical debt and tracking technical debt so you can pay it back. That's OK that they want to talk about technical debt, but sometimes I see them using Ward's debt metaphor as validation for this practice. Taking shortcuts, like not pairing, not doing TDD, not automating your acceptance tests, or just plane not writing clean code or refactoring to clean code will actually hamper your ability to pay back your design debt because now your code does not express the knowledge you have about the system as well as it should. You are cheating yourself in two ways. You are creating technical debt that the team will have to pay back in the form of refactoring or, more often, bug fixes, and you are severely hampering your ability to pay back the design debt because the code does not clearly express current design knowledge.

What's the point? First, don't take shortcuts. Be honest and firm with your customer and tell them that you are sorry, but she can only have 2 of the 3 must have features for the upcoming trade show. And second, if you think it's OK to go into technical debt to please your customer, don't think that is what the debt metaphor enables. For the debt metaphor to work, you absolutely can not go into technical debt. Period.