Last updated on July 7th, 2021 at 11:08 am
Decisions to defer technical debt retirement must take into account phenomena that if left unattended can lead to three undesirable outcomes. First, deferring technical debt retirement can increase the volume of the deferred class of technical debt. Second, deferring technical debt retirement can increase the volume of other existing classes of technical debt. And third, deferring technical debt retirement can generate new classes of technical debt.
An example of debt contagion
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.
Lessons learned from this example
The lesson here isn’t to ban scriptable applications. Nor is the lesson to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The main lesson this example provdes 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]. Because of debt contagion, 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].
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 hardware and software interfaces can propagate technical debt. This is ironic, because interfaces were conceived to insulate one portion of an asset from others. Given a system S composed of modules, suppose that module M of S provides services other modules of S. M does contain 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, MPrin expansion can repeat whenever new modules appear in S. But even if we do provide alternatives, engineers must consciously adopt them. Although some will, others 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.
- A policymaker’s definition of technical debt
- Debt contagion: how technical debt can create more technical debt