Technical Debt is a common topic these days. How is it incurred? How should we track it? When should we pay it down?
It is a metaphor commonly understood. Our customers get it. While they may not like it, they do understand. Technical Debt is incurred today and needs to be paid down; preferably sooner rather than later what with compound interest and all that.
Technical Debt is accepted by many as a natural part of the development process. Frankly, I agree. I think Technical Debt is a good thing to take on for short periods of time. Perhaps it is even unavoidable in some cases. Therefor we should expect it and deal with it accordingly.
But there is something insidious going on here. In many cases, perhaps even most cases, what developers are really talking about is code that is not Clean.
And Messy Code is not Technical Debt.
What is Technical Debt?
Ward Cunningham coined the phrase Technical Debt.
"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. Objects make the cost of this transaction tolerable. 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, object- oriented or otherwise."
As he clarifies later in a You-Tube video, Ward was specifically talking about design decisions made in the course of developing software that allowed for more rapid delivery. Rapid delivery not for the sake of meeting a deadline. Rapid delivery to elicit quick feedback, thereby providing the data necessary to adjust the design to be more congruent with actual needs. The object design should change to reflect your current understanding of the domain, even if that understanding is partial. Technical debt is payed back through code refactoring as our understanding of the domain matures.
Ward clearly states, "The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem."
MISUNDERSTANDINGS ABOUT TECHNICAL DEBT
Ward's original description was vague. His clarification which later followed may have come too late. Many had already taken the phrase and added their own flavor to it. Martin Fowler discusses Technical Debt and even refers to Ward's definitions, but then goes on to say "doing things the quick and dirty way sets us up with technical debt". Jeff Atwood also allows the phrase "quick and dirty" to creep into his explanation of Technical Debt. And in an Intel posting, the definition is expanded to:
"Technical Debt is loosely defined as the volume of poorly written lines of code, poorly refactored, not following coding standards, not supported with sufficient unit tests, and the amount of code duplication."
This seems to be the common definition of Technical Debt today. And it is most unfortunate.
Messes are not Technical Debt
Poorly written code, lack of standards, lack of tests, code duplication, multiple responsibility, complex interfaces, large classes, poor/insufficient error handling, and opaque intent are all messes. Not a one of them is Technical Debt. And as such, none of them should be categorized as Technical Debt. For a comprehensive listing of messes, see Robert Martin's Clean Code.
Messes Preclude Technical Debt
Technical Debt is paid back through refactoring as our understanding of the domain matures. "The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem."
Clean Code is actually a prerequisite for Technical Debt. If you don't have Clean Code, you cannot expect to pay the debt back. If you have a mess, you cannot reasonably incur Technical Debt. In fact, you are not incurring debt, you are merely adding to the existing mess.
Messes are not Acceptable
Uncle Bob has stated, "There aren't any reasons to make a mess."
I don't entirely agree with Bob on his point. I think there aren't any reasons to leave a mess. TDD encourages us to take tiny steps. Some of these steps result in small messes. Messes that we will clean up in very short order. But we've made a mess nonetheless. And there is no shame in having done so. To leave the mess for any significant period of time or to allow more mess to accumulate is, however, unacceptable.
Stop calling messy code "Technical Debt"
Stop hiding behind the term Technical Debt. If you have messy code, clean it up. Implement the Boy Scout Rule and get it taken care of.
Most important - don't treat the permeation of mess into your system as something natural and acceptable.