The original coining of the phrase "technical debt" came from Ward Cunningham (you can watch Ward describe it in his own words on):
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.
This reporter recently had a conversation with a few colleagues about technical debt and it's solution. The gist of the argument was this: this reporter believes technical debt is a technical issue that can be solved by a disciplined approach to refactoring which necessitates a saftey net of tests, the other side argued that refactoring and testing were not necessary to reduce technical debt and they were not sufficient.
The first side of the argument can be summarized breifly as: to reduce technical debt people have to stop digging and incrementally add tests and refactor so that the design and architecure of the system can first catch up to, and then keep pace with the changes in the real world problems the system is addressing. The understanding of technical debt here is that it is a technical problem and should be managed. You can take on technical debt as you see fit and should pay it down regularly. Martin Fowler, Ward Cunningham, (uncle) Bob Martin, and many others have written about this topic, it's importance, and what it means to development teams.
The other point of view does not contradict the previous one, but suggests that this is a small part of the real problem and that we can address the symptom and not solve the root cause if we are not careful. In fact, we have been refactoring even before the emergence of TDD and the coining of the term "refactoring". We, software developers, would redesign and rebuild systems which is just refactoring with a much larger cycle (months and years instead of minutes). Therefore TDD and refactoring are only addressing the symptom. They quote Deming:
This is not ranking people. He needs to understand that the performance of anyone is governed largely by the system that he works in...
Which means that technical debt is a symptom of a larger problem of little to no visibility of the debt itself to anyone other than developers and the system - i.e. the organization - creates an environment where the technical debt is allowed to grow uncontrollably. Hence, the solution is in the system and in making the problem and costs transparent and not in giving developers a new toolset.
This reporter personally needs some time to digest this argument and felt it was important enough to share with the community.
Community comments
Another aspect of technical debt
by Matt Giacomini,
Re: Another aspect of technical debt
by Mr Magoo,
I agree that Technical Debt is not a technical issue
by Jun Ran,
Technical Debt is a business issue.
by Chris Matts,
Rebuild is not refactoring
by Matt Southerden,
Another aspect of technical debt
by Matt Giacomini,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have experienced another form of technical debt, based on unneeded features. Some features add large amounts of technical complexity to the code of an application, and in some cases these features are barely used, or totally unused. Generally product managers and/or business analysts are unwilling to sign-off on removing features. Even when the complexity of said features are impacting speed of development and/or the ability of application developers to tune a system for maximum performance. In the end I have seen large high paying customers affected by "debt" incurred for small customers, or to hold on to features "just in case".
As stated above I think that organizations see technical debt as being a developer problem. Either because a developer (or group) is lacking skill, or has just not gotten around to "fixing the problem".
I do not feel that all forms of technical debt can be refactored away or fixed by adding more unit tests. Application performance, learning curve for new developers, and troubleshooting are all affected by the level of complexity of a given application, which in itself is a form of technical debt.
Re: Another aspect of technical debt
by Mr Magoo,
Your message is awaiting moderation. Thank you for participating in the discussion.
I believe that is what is referred to as waste.
In this case it appears to be waste that also came with large amounts of technical debt. :)
Semantics...meh.
I agree that Technical Debt is not a technical issue
by Jun Ran,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is a systemic issue, an issue about people, about the organization, about the cooperation.
Technical Debt is a business issue.
by Chris Matts,
Your message is awaiting moderation. Thank you for participating in the discussion.
Technical Debt is a business issue. Technical Debt causes real business issues and should be treated as such. Technical People should explain the symptons of technical debt to the business in business terms. These are normally "performance of the system", "stability of the system", "chances of a significant bug being introduced to production (risk)", "development turn around time" and "realiability of the development process".
There are causes of technical debt...
One is caused because the business are in a hurry and IT have to cut corners.
Another is what I call Emergent Technical Debt. The business environment changes and the design no longer supports it properly. The system limps along for a while with IT applying hacks to the system.
The worst kind of technical debt is due to bad design caused by ignorance or a lack of caring on the part of developers.
The strategy for paying down technical debt problem really depends on the context.... from complete rewrite to refactoring.
However, the decision to pay down any technical debt ( apart from small refactorings which are part of the cycle ) should be a business decision with real business benefit. If you articulate the symptoms of technical debt in terms the business investor will understand, they will often support you. If they do not, well its their money and its their decision.
Rewriting the code just because you do not like the style is not a valid reason.
I think Technical Debt is a misleading term. You have to repay debt. A better way to think of it is as selling a call option on the application. If the business do not want to use the application, then the call is worth nothing. The more the business use the application and change it, the more the option is worth and hence being short hurts more.
Rebuild is not refactoring
by Matt Southerden,
Your message is awaiting moderation. Thank you for participating in the discussion.
I disagree. Refactoring is improving the design, readability, and malleability of existing code. I have seen many rebuilds embarked upon with the intention of improvement. But while a new system may emerge with a different (not nessessarilty greater) feature-set, they rarely improve the code on a line-by-line basis.