The other day I was reading an article by Martin Fowler in which he referred to the term technical debt. He credits Ward Cunningham for coining the term, which is defined thusly:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
This is a nice, business-y way to discuss a problem every developer is familiar with. You could publish a blog just on ways projects incur technical debt and how to address those problems. In fact, I’d argue that one of the primary jobs of a team leader or manager on a technical team is to spot places where technical debt is being incurred so that it can be addressed later on.
The burden falls on the person leading development, because nobody else involved in the project is going to take care of it. The product manager (or project manager) are properly focused on budget, schedule, and specifications. The quality assurance team is focused on making sure the application produces the right output given the right input. Only the developers themselves can be responsible for reducing or avoiding technical debt while addressing the other audiences.
I think that most of the worthwhile fights that developers have with other members of the team are over issues of technical debt, it’s just that few people refer to it that way.
Expect more posts on technical debt in the future.
February 14, 2009 at 7:30 pm
Great term, reminds me of when as a new homeowner, I finally got a handle on the phrase “deferred maintenance” whichis sort of similar.
February 16, 2009 at 9:13 am
Rafe,
Do you think the technical debt has to be paid off with a balloon payment? It seems to me like you can’t really pay off this kind of debt on a 30-year fixed interest model, it all comes due at some point in the future and must be paid in full, at once, in order to move beyond it.
Or can you refactor code consistently and in essence pay it off with small payments over time?
February 16, 2009 at 11:11 am
Good question. I think I’ll answer it in another post.
February 18, 2009 at 4:59 pm
Good post!
However, I’d point out that a big part of the problem is that typically it is someone else who ends up paying the interest while the creator has gotten the major portion of the credit for on-time delivery or whatever and already “flipped” the code.