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.