Ward Cunningham
http://www.youtube.com/watch?v=pqeJFYwnkjE
Borrowing money is good... rushing software out the door to get some experience with it is a good idea, but of course you would eventually go back and as you learn things about the software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Plenty of cases where people would rush software out the door and learn things but never put that learning back into the program... analogy = borrowing money thinking you never had to pay it back. Eventually all your income goes to interest and your purchasing power goes to zero.
By the same token if you develop a program over a long period of time by adding features but never reoganise to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer, in other words the interest is total and you make zero progress.
A lot of bloggers have confused the metaphor to mean you can write code poorly with the intention of doing a good job later
Borrowing money is good... rushing software out the door to get some experience with it is a good idea, but of course you would eventually go back and as you learn things about the software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Plenty of cases where people would rush software out the door and learn things but never put that learning back into the program... analogy = borrowing money thinking you never had to pay it back. Eventually all your income goes to interest and your purchasing power goes to zero.
By the same token if you develop a program over a long period of time by adding features but never reoganise to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer, in other words the interest is total and you make zero progress.
A lot of bloggers have confused the metaphor to mean you can write code poorly with the intention of doing a good job later
Martin Fowler
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.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
Wikipedia
Coding Horror
No matter how talented and smart the software developers, all these tiny deferments begin to add up and cumulatively weigh on the project, dragging it down.
I believe that accruing technical debt is unavoidable on any real software project. Sure, you refactor as you go, and incorporate improvements when you can -- but it's impossible to predict exactly how those key decisions you made early on in the project are going to play out. All you can do is roll with the punches, and budget some time into the schedule to periodically pay down your technical debt.
Steve McConnell
One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.
How do You Make an Organization's Debt Load More Visible?
One organization we've worked with maintains a debt list within its defect tracking system. Each time a debt is incurred, the tasks needed to pay off that debt are entered into the system along with an estimated effort and schedule. The debt backlog is then tracked, and any unresolved debt more than 90 days old is treated as critical.
Another organization maintains its debt list as part of its Scrum product backlog, with similar estimates of effort required to pay off each debt.
Either of these approaches can be used to increase visibility into the debt load and into the debt service work that needs to occur within or across release cycles. Each also provides a useful safeguard against accumulating the "credit card debt" of a mountain of tiny shortcuts mentioned earlier. You can simply tell the team, "If the shortcut you are considering taking is too minor to add to the debt-service defect list/product backlog, then it's too minor to make a difference; don't take that shortcut. We only want to take shortcuts that we can track and repair later."
Object Mentor
Fulhack
Annotation based hack reporting tool
Resharper
http://creedcultcode.blogspot.com/2008/04/tracking-technical-debt-in-resharper.html
// HACK, // TODO, // DEBT
Use Maven Taglist Plugin
http://mojo.codehaus.org/taglist-maven-plugin/
http://stackoverflow.com/questions/1989177/how-to-manage-todo-programming-stuff
Resharper
http://creedcultcode.blogspot.com/2008/04/tracking-technical-debt-in-resharper.html
// HACK, // TODO, // DEBT
Use Maven Taglist Plugin
http://mojo.codehaus.org/taglist-maven-plugin/
http://stackoverflow.com/questions/1989177/how-to-manage-todo-programming-stuff
