Over the last couple of years I have been more or less following the technical debt community's discussion on what exactly is technical debt. Some ague that technical debt is limited to what it would cost to address deficiencies such as those found by code inspection tools such as Sonar. Other writers such as Chris Stirling introduce aspects or kinds of technical debt: quality debt, design debt; ....
My interpretation of the Ward Cunningham metaphor on incurring debt by shipping is broader, including the wide range of after-delivery costs. This entry is continue that discussion and suggest one path forward.
I argued that technical debt should reflect the fact that the very act of shipping software incurs all sorts of possible liabilities, any one of which may incur some future cost.
- Future service costs
- Executives getting on planes to deal with critical situations
- Fines resulting from privacy violations
- Loss of business from failing a compliance audit
- Loss of intellectual capital due to security flaws
- etc, etc.
The nature of the liabilities very from domain to domain. Shipping the next rev of a mobile game like angry birds entails much less liability that next rev of avionic software for a commercial jet.
The costs of fixing the code may be the least of it and under-estimates the assumed labilites. Reasoning about whether these liabilities outweigh the benefits of shipping the code is key to the ship decision.
Since I wrote that entry I have been watching the technical debt space and see that I may be the minority, but not alone, with this perspective, Some people argue that technical debt is solely the cost of addressing shortfalls in the code. Others adopt a broader definition. In fact, in a conversation I had with Capers Jones, a long-time expert in software measurement, he shared a conversation he had with Ward discussing the same points. I have seen others make a distinction between software debt and technical debt. I have decided not to weigh in on this argument, but suggest we call all of the liabilities, (wait for it ...) technical liability.
There is a key difference between standardly-defined technical debt and technical liability: Technical debt involves code quality and can be determined. The liabilities involve possible future events and so entail predictions of the future. Some might even consider technical debt knowable and technical liability unknowable.
Readers of this blog know where I am going. Technical liability, unlike the more limited technical debt, involves a range of future possibilities and so each of the components of liability should be specified as a random variable with a probability distribution. The security violation might or might not occur. But if it does, the possible expense could sink the company. Reasoning about the risk takes some advanced techniques like setting the price of an insurance policy.
Finally, the economic decision if it makes sense to ship a piece of software, one needs to balance the value expected from the ship against the assumed liabilities. Note that the future value is also a random variable. In that case the decision to ship should be based on the techniques found here. I will elaborate the reasoning ibehind technical liability n a future blog (promise).
In summary then, technical liability gives a more complete picture of the economics of shipping a piece of code than technical debt, but it requires more sophisticated analysis.