If your organization measures technical debt, have you really considered why you're doing this, and what you will do with that information once it has been gathered? Just because you can measure technical debt doesn't mean you should. Before you start (or continue) measuring technical debt, it's important to recognize that there are consequences.
Many organizations examine their software development efforts to identify technical debt. If yours is one of the many organizations measuring technical debt, have you really considered why you're doing this, and what you will do with that information once it has been gathered? Have you also considered what business risks it could entail?
Just because you can measure technical debt with one of the growing number of tools that calculates it automatically doesn't mean you should. Before you start (or continue) measuring technical debt, it's important to recognize that there are consequences.
I believe measuring technical debt can be quite valuable—in the right context. If the business can define what's expected for a requirement to be considered complete (the definition of done) and can automatically and quantifiably measure if that's being achieved, there is distinct value in measuring technical debt. But even then, you have to be prepared for the fact that the gap you've exposed could have far-reaching consequences.
Maybe your development team started measuring technical debt because someone thought it would be interesting. Then, your software fails one day, and that failure results in serious physical or financial damage. This notion of "technical debt" could come back to haunt you—particularly if your software development process lacks the maturity to handle these situations.
Imagine that the following testimony is occurring in front of a jury.
Prosecutor: Does your organization measure the concept of "technical debt"?
You: Yes.
Prosecutor: What is technical debt?
You: Well, technical debt means that there is work yet to be done.
Prosecutor: Did this software have any known technical debt when you released it?
You: Yes.
Prosecutor: So you've saying that you deliberately released this software—the software that caused [insert nightmare scenario here]—when you were fully aware that there was necessary work left to be done?
You: [Gulp] Well, yes. But …
Just think how incriminating this looks. Even if the bulk of your technical debt can be attributed to something like poorly documented code, try explaining the technical nuances to the typical jury. It's undeniably a slippery slope.
With software being, for the most part, so simple to update, it's quite common for organizations to release software they know is not perfect or complete. However, if you're deliberately measuring and recording this gap as technical debt, be aware that releasing software with documented technical debt could introduce business liability. Even if that technical debt is not directly related to a defect that caused substantial damage, would you want to be standing in front of the jury in the scenario outlined above?
But let’s say you have a well-defined risk-management policy and processes that facilitate the identification of technical debt and communicate the risk in the context of IT governance, complete with a strategy for mitigating those risks over time. Wouldn't you feel a little more comfortable in this situation?
Another risk of measuring technical debt is that it could impede the pace of innovation. If your technical debt charts show an escalating amount of debt, don't be surprised when the development team later uses this technical debt to explain why they can't deliver the features you need within the timeline you want.
The bottom line is that if the business doesn't consider certain "work left to be done" as something that absolutely must be completed soon, then don't call that work technical debt. Rather, record it in a backlog or some other area that is used to store ideas. You can also document your efforts to ensure acceptable quality through robust test policies, procedures, and, of course, automation. Otherwise, you risk inflating your debt and escalating its potential to backfire.
You might be wondering what the difference is between measuring technical debt and recording defects or publishing known issues. One key difference is that anything you label debt instantly gains a negative connotation; it sounds both deliberate and dicey. Although defect-tracking systems could be used to store defects discovered prior to release, they also commonly serve as a repository for field-reported issues that warrant further investigation. And although publishing known issues discloses the fact that a release is not perfect, it does demonstrate that you're working in the spirit of caveat emptor.
Regardless of the negative connotations, there is a time and place for measuring technical debt: when business and development teams have come to a mutual understanding and are truly committed to ensuring that software meets predefined expectations and they want to estimate the resources required to reach that level. However, if you plan on releasing software with quantified technical debt, be well aware of the risks of this "premeditated" trade-off. Think long and hard about whether you'd be willing to defend the business impact of the definition as well as publish the number in the company's public records and statements.
Is knowledge power, or is ignorance bliss? In today's competitive landscape, you need to be able to respond to customer needs as quickly as possible while also ensuring that your code is of sufficient quality. Successful companies learn to balance productivity and quality to the delight of their customers and their shareholders.
