Technical Debt is a metaphor coined by Ward Cunningham (the inventor of the wiki) which can be used to change the mindsets (and perhaps culture) of development teams when it comes to Quality in software development.
What is Debt (the Money thing)?
We all know that when we take a loan from the bank (Housing, Car or Personal) we think about it quite a lot and sometimes it could be a source of worry as well (or at least we never forget about it, it’s always there in our heads 🙂 )
The bigger loans you take the more interest you need to pay and if you don’t try to reduce the principal you will continue to pay interest for a long period.
OK that’s the money side of things, so what is Technical Debt in software development?
I’ll start by asking a few familiar questions…
- Have you ever felt that the initial design of your code was not very good since you did not have the ‘perfect’ understating about it at the beginning?
- Have you ever done a quick and dirty (Q&D) bit of coding to get your software delivered shipped before its deadline?
- Have you ever ignored a warning from your static code analyzer because you had a more important development task to carry out?
- Have you ever avoided writing a unit/functional test since there was a major piece of functionality to be delivered to your customer the next day?
When you have done (I know I have done :)) any of the above you are basically taking a loan from the software being developed. Like the bank loan, the technical debt results in interest payments…
Ok, I think I better let Martin Fowler explain this…
“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”.
The key point here is that, it maybe OK to incur technical debt (depending on your situation) but you should always manage your debt within your development team and don’t let your debt grow so much out of control that making a small change(or bug fix) in the software takes way too long due to bad design.
Now have a look at the explanation given by Cunningham himself (since he is the best person to explain it :))
So make sure your team’s technical debt does not grow out of control and spend some time refactoring and improving the codebase and reduce your technical debt periodically (like paying down the principal of your bank loan :))
These are the best few blogs that I found that explains ‘Technical Debt’
http://martinfowler.com/bliki/TechnicalDebt.html (Fowler’s blog)
http://c2.com/cgi/wiki?TechnicalDebt (Cunningham’s site)