Last updated on February 17th, 2020 at 08:10 pm
Decisions to defer technical debt retirement must take into account phenomena that if left unattended can lead to three undesirable outcomes. First, it can increase the volume of the deferred class of technical debt. Second, it can increase the volume of other existing classes of technical debt. And third, it can generate new classes of technical debt. An example can illustrate this behavior.
Suppose we have a fleet of desktop computers, running a mix of operating systems. A few of these systems are running Windows 8 and the rest are running Windows 10. We’d like to upgrade the Windows 8 machines to Windows 10, but we can’t, because some of their users need access to a (fictional) scriptable application called CRUSH. CRUSH isn’t available for Windows 10. CRUSH for Windows 10 is promised “shortly.”
Instead of asking our CRUSH users to find an alternative to CRUSH, we defer the Windows 8 upgrade. We’re hoping that CRUSH for Windows 10 will soon arrive. Meanwhile, other Windows 8 users are happy to continue using Windows 8. Some of them have acquired — and have grown fond of using — another similar (fictional) scriptable package called REMOTE. REMOTE is also unavailable for Windows 10. Worse, the CRUSH user community is continuing to grow.
Thus, by deferring the Windows 8 upgrade, we’ve made space for additional problems preventing the upgrade to Windows 10. The technical debt associated with the Windows 8 upgrade now includes Windows 8 itself, and all the scripts, documents, and knowledge that are accumulating for both CRUSH and REMOTE.
The lesson here is not to ban scriptable applications. Nor is the lesson to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The point of the example is that deferring debt retirement can enable formation of new instances of existing technical debt. In this example, the new debt includes the growth of the CRUSH user community with the assets they continue to develop, New debt also includes unrelated debt connected with the introduction of REMOTE. Thus, if we defer retirement of one class of technical debt, we must consider all costs of such deferment. Those additional costs can include expansion of the total volume of technical debt, and all its consequences, as expressed as metaphorical interest charges and MPrin.
Some of the new technical debt that forms when we leave existing debt in place is closely related to the existing debt. For example, once we’ve implemented some part of an asset in a way that we now acknowledge contains a form of technical debt, we tend to apply that same approach when we undertake extensions or enhancements, rather than using what everyone might acknowledge is a superior approach.
Introduction to debt contagion
Martini and Bosch have identified a phenomenon they call debt contagion [Martini 2015], whereby creating new system elements in forms compatible with elements already identified as debt causes debt propagation. This practice helps us maintain some degree of uniformity in the asset, recognizing that in doing so we’re increasing the MPrin of a given class of technical debt. These future expansions of MPrin can be difficult to predict at the time we first incur the debt, or at any time.
However, some forms of technical debt are far less discriminating with respect to the kinds of technical debt they spawn. Debt with this property tends to be associated with the processes used to develop or maintain technological assets. In “A policymaker’s definition of technical debt,” we cite Pugh’s example of acceptance test debt as a form of technical debt [Pugh 2010].
But acceptance test debt can reduce the ability of the organization to retire other forms of technical debt. Absent automated acceptance tests, testing system components from which technical debt has recently been removed is less efficient and reliable than it would be if automated acceptance tests were available. This depressed efficiency and reliability retards debt retirement activity. It might even prevent the organization from attempting debt retirement in some circumstances. In a future post, I’ll describe how a deficient regime of reviews and inspections can also lead to incurring new technical debt, or to elevated levels of legacy technical debt.
Our final example illustrates how interfaces — which, ironically, were conceived to insulate one portion of an asset from others — can act so as to propagate technical debt. This example could apply to either hardware or software. Given a system S composed of several modules, suppose that module M of S provides services of some kind to several other modules of S. M does contain some technical debt, of a form whose retirement would simplify M’s interface. Because that change would require changes to the modules that use M’s services, we decide to defer retiring M’s debt. Meanwhile, other projects are introducing new modules into S, and, of course, they must use M’s existing interface. The MPrin of the technical debt associated with M’s interface thus expands.
Unless we provide an alternate version of M (call it M’) or an alternate interface to M, this process of MPrin expansion can repeat whenever new modules appear in S. But even if we do provide M’ or an alternate interface to M, engineers must consciously refrain from using the older approaches. Some will refrain, but some might not. Some are under severe schedule pressure. Some cannot or will not learn the new approaches. And some receive direct orders not to use the new approaches. The MPrin associated with M can thus continue to expand, albeit perhaps at a reduced rate.
Technical debt, left in place, can grow and spawn new forms of technical debt. Make technical debt retirement a priority.
[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.
[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.
[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.