Technical Debt Reprise
Some of you are familiar with my prior material on Technical Debt. Many of you may not be. So let’s go over it quickly.
Technical Debt as originally defined is the gap between what has been implemented and what we now know we need. It is primarily a reference to code that would benefit from refactoring and secondarily a reference to code that provides functionality which does not entirely meet the customer’s need(s). By the original definition, you could not have Technical Debt if you had messy code.
Technical Debt Today
Today, the definition of Technical Debt is practically the opposite of the intent. When people say Technical Debt, they usually mean messy code. You can imagine the side-effect of taking something well intentioned, inverting it, and acting like it is the same thing. Kind of like a water filter that adds contaminants to drinking water, but is sold like any other water filter.
I no longer believe we can return to the original, healthy and helpful definition of Technical Debt. Nor do I think we’re going to shift away from it to a better metaphor.
But maybe we can talk about remediation of Technical Debt in a way that helps us make better decisions.
Types of Remediation
The way I see it, Technical Debt Remediation is nothing more than Maintenance. Maintenance is to keep in an existing state (as of repair, efficiency, or validity) or to preserve from failure or decline.
Technical Debt Remediation (Maintenance) comes in different categories – Preventative, Deferred, and Repair.
Preventative
Preventative Maintenance is essentially refactoring– work that improves maintainability. Preventative Maintenance is good stewardship and, much like preventative maintenance in automotive or factories, is the least expensive in the long run. The primary objective of preventative maintenance is to prevent or significantly reduce the likelihood of failure.
In code, I believe the best strategy is to perform preventative maintenance as you go along. This is primarily refactoring the code to a better composed, more legible solution.
Assuming it is work done in real-time as stories are implemented, Preventative Maintenance should not be separate cards in the backlog. It might be part of the Definition of Done for a story.
Deferred
Deferred Maintenance is when we deliberately delay certain work in exchange for faster delivery of value. This typically happens when we realize a need for a significant change - say upgrading to the latest release of Java or adding in more stringent security requirements now that the application is gaining traction.
Deferring this work can benefit the company in the short term, but deferring for too long can result in issues. Often times, when this work is deferred, we find that the system is “working”, but may experiencing performance difficulty due to neglect.
Deferred Maintenance usually shows up as stories or even features/projects.
Repair
Repair is when Deferred Maintenance has resulted in outages, sporadic or chronic. Repair is usually done under duress and often fails to address core issues whereas Deferred Maintenance is usually done in a larger project.
Repair usually shows up as a defect (or defects). The system is down or at least some users are being adversely impacted. The business may suffer. These fixes are often insufficient as they fail to address root causes. Once the emergency is over, preventative maintenance is not performed, resulting in greater amounts of deferred maintenance and, ultimately, more repair.
Conclusion
I’m clearly mixing metaphors; Debt and Repair. We don’t tend to think of these things together. I encourage you to consider it. As Technical Debt isn’t financial debt, we need not think of it in entirely similar ways. I encourage you to consider the language of maintenance as you work with your code and systems. What strategy makes the most sense for you in the short term and long term? Preventative maintenance, deferred maintenance, or waiting until repair is necessary? Perhaps it is a mix.