QWANtify is excited to announce, effective May 1, 2010, their purchase by Safe Bridge Solutions, Inc. of Madison, WI. Read More »

Technical Debt

February 28, 2009 · by Administrator

I read a very interesting article this past week by Martin Fowler about technical debt1. Fowler explains Technical Debt, a term originally developed by Ward Cunningham2, this way:

“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.”

I’m sure every software developer can relate to this problem Except in rare cases, it’s necessary for a long term project or application to incur some debt due to time or implementation constraints. The key is how this debt is managed going forward, if at all. Some will choose to build upon an already faulty architecture, incurring even more debt which will have to be dealt with down the road. Others will make small, quick refactoring changes to slightly improve the situation. The worst case scenario would involve the debt getting so bad that massive refactoring must be done, costing a company more money than if they would have taken more initial development time.

The other factor to consider with technical debt is the fact that the original developers may not be around to “pay it off”. It could fall to someone else unfamiliar with the original design decisions and overall architecture, which can lead to even more cost.

The big question is how to best mitigate and handle technical debt. I’m curious to know what sort of approaches others have seen taken. How much debt is too much? Who is responsible for making sure this debt is repaid and doesn’t affect the project/company going forward? Should it be the managers or the developers? And how much time should be spent fixing old code? Please share your thoughts.

[1] http://martinfowler.com/bliki/TechnicalDebt.html
[2] http://en.wikipedia.org/wiki/Ward_Cunningham

Filed in: Team Member Blog Comments (1)

Comments

#1 - Steve Alvarez said on Mar 16, 2009:
Well, I can admit to having been part of project teams that have had to incur some form of “technical debt”.  I think this falls under the umbrella of project scope management, and thus should be subjected to how your team manages any other type of change in the project (e.g.; requirements changes).  The best way I have seen this handled is by having good communication among all team members, including stakeholders, so that the advantages and disadvantages can be weighed against each other.  Sometimes there’s a need to cut corners in order to get something working and out the door, but ultimately someone will end up paying for this in the future.  This is where the communication between team members will be needed to arrive at a decision to the question of “If we do this now, who is going to have to pay for this later?”  In addition, having good documentation about any concessions made will help to hopefully keep the issue alive, and help whoever has to fix or compensate for it in the future (especially if it’s not the original project team).
Commenting is not available in this section entry.