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.