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.