The metaphor of “technical debt” is gaining in popularity to describe the implications of taking shortcuts in developing software. Steve McConnell has an excellent post on technical debt, where he begins his discussion:
The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.
As many others have already already written on this subject, I will instead focus on this question from his summary:
What do you think? Do you like the technical debt metaphor? Do you think it’s a useful way to communicate the implications of technical/business decision making to non-technical project stakeholders?
Firstly, yes – I believe the technical debt metaphor is a useful way to communicate such implications to non-technical stakeholders. I’m sure most developers can relate to some version of a conversation going something like this:
The Big Boss: Thanks, that was an excellent demo! Let’s make sure to get this into tomorrow’s release!
You: Umm… I still have some things to finish up. I’m planning to have it ready for testing sometime next week. I am on track to meet the scheduled deadline.
The Big Boss: Finish up? Everything is working great! What do you have left to do?
You: Well, there’s just a few changes I need to make… strengthening the exception handling, making a few improvements to the design, cleaning the code up a bit…
The Big Boss: Ah, don’t worry! The demo looked fine to me and the customers don’t care about all that! Besides, Friday is the end of the quarter and it will be great to get this feature out now!
Of course, as developers we try to explain to The Big Boss that we still need to do the last iteration of refactoring. We want to deliver code with a level of quality that we expect of ourselves. However, often The Big Boss cannot relate. Or, at least, he doesn’t think it’s as important as we do. In this situation, the technical debt metaphor can be an helpful way to describe such issues using terminology that he is more likely to appreciate.
Although the metaphor can be useful, it also has some important shortcomings. These shortcomings are especially significant in dealing with non-technical stakeholders.
Concern # 1 – The term “debt” is too soft
Financial debt is abundant and widespread, often accepted as a fact of life. I agree that some level of technical debt is also unavoidable in doing real software development. However, especially with a non-technical manager, the decision may be made too readily to accept technical debt without understanding the full implications.
“Interest rates” are usually low
The metaphor of “interest payments” is used to illustrate the implications of taking a more “quick and dirty” approach. In these days of low interest loans, the connotations of this analogy may not be strong enough to describe the real impact of accepting lesser quality workmanship.
Concern # 2 – The “Interest Rate” Varies
When describing technical debt, the individual issue incurring the “debt” should be highlighted in terms of severity (it’s interest rate). Take two possible examples of technical debt a team may choose to incur:
- Refactoring to improve naming of methods/variables of a new class is not performed.
- Unit tests are not created on this same new classes.
The first example of debt may certainly impact readability/maintainability, particularly in the long run. However, this is probably not severe and would probably be fairly to change in the next release or two. It is this type of debt where the use of this metaphor seems most appropriate.
The second example of debt is more severe and will be harder to “service”. The initial code will be released without sufficient testing from the beginning. Unnecessary dependencies may have been introduced that are difficult to extract later. Future development may be severely hindered without the “safety net” of unit tests to refactor… Whatever the impact, the point is that each instance of technical debt is different and must be considered independently.
Summary – Should quality be compromised? When?
In any case, my biggest concern is the metaphor of technical debt seems to open the issue of quality as being a gray area, something that can be “traded away”. The decision to compromise quality should not be made lightly under any circumstances.
Update: My next post further describes the issues of compromising quality