I'm going to be on a panel to discuss Technical Debt at SPLASH 2013 and have been collecting information on TD in preparation for it. It's interesting to note that Ward Cunningham never actually uses the term "Technical Debt" in the 1992 OOPSLA experience report. He only ever mentions the term "debt analogy Metaphor" and "going into debt". As far as I can tell, the term "Technical Debt" was first attributed to Dave Smith by Johanna Rothman in an article she published in 2000.
After analyzing what Ward Cunningham says in his 2009 video posted on YouTube, I tend to think that Ward and Uncle Bob think the same way about "debt" in software. If you're going to choose to go into "debt", then your software better be well-factored and understood so that you don't have to pay a lot of interest in making it reflect newly found understanding of what the system should be doing. My interpretation is that "debt" in the sense that Ward uses it refers to an incomplete understanding of what the software does or should do. Ward considers it a GOOD strategy to go into debt so that you can get a better understanding of the software. You can then go back and apply whatever you learned from running the immature program and make it reflect your new understanding. This would be a good strategy in the context of doing test-driven development (or test-first programming as it was known back then) and the practice of merciless refactoring. Going into debt without ever going back and making the software reflect any learnings basically amounts to not paying back what you owe, and this is what kills us as developers.
Nice to realize that Ward never used the term "Technical Debt".
Temporarily, it could be beneficial (in terms of time to market) to introduce technical debt; however, realizing this that we are achieving the goals (time to market) at the cost of technical debt is not common. This non-realization makes the topic interesting.
T. Sharma wrote:Temporarily, it could be beneficial (in terms of time to market) to introduce technical debt; however, realizing this that we are achieving the goals (time to market) at the cost of technical debt is not common. This non-realization makes the topic interesting.
I really would not use the term "introduce technical debt" because it should be about choices and trade-offs.
In the example that Uncle Bob gives in his article, the choice was between a design that used frames vs one that used AJAX. The constraint was time, or more precisely, the lack thereof to write an AJAX framework. If you go back to the common Construction metaphor, you can choose to have vinyl tiles instead of ceramic tiles for your floors because of budget constraints. You can then decide later on to upgrade to ceramic tiles or a different material when you are in a better financial position to do so. Until then, the vinyl tiles may work for you just fine.
Author Esther Derby has a talk entitled "The Language of Change" in which she points out that we should carefully choose the kind of language we use to discuss changes that come with a move to Agile development. The need to carefully choose language is related to the kind of mental images that certain words and phrases create in our minds. Some images can give us the wrong impression or lead us down unproductive paths of thought. I think the same applies to any discussion that deals with abstract topics such as the Debt Metaphor.
When we talk about the Debt Metaphor, I think we should be very careful about the kind of terms we use so as not to contribute to the semantic diffusion of the term. I doubt that the term "Technical Debt" will ever go away at this point but I think that the way it is commonly used nowadays tends to muddle the intent Ward originally had in using it, which was to explain the refactoring that they were doing on the WyCash project. In Ward's mind, going into debt was a GOOD strategy because it allowed them to gain more understanding of the program and consolidate the code and design through refactoring.
To stick with the original intent of the Debt Metaphor, you could say that you "make a choice" or "decide" to go into debt because of certain constraints: time, skill, technology, etc. When you say "introduce technical debt," the term conjures images of programmers purposely writing messy code or just going with a poor design. For some reason, this tends to justify the kind of unproductive behavior that gets everyone in trouble. You could argue that the same goes for "make a choice" and "decide" but I think these terms give you a better sense of the kind of thought process that you should have when considering what to do about your code/design.
Another interesting thing to note is that Esther's talk is based on the work of George Lakoff, the same UC Berkeley professor whose work inspired Ward Cunningham to come up with the Debt Metaphor.