Last updated on July 17th, 2021 at 06:53 am
When technical debt appears as discrete chunks—when it’s localizable—we can often retire the debt incrementally. We can retire it system-by-system, module-by-module, or even instance-by-instance. These approaches offer great flexibility, both technically and financially. That makes retiring localizable technical debt a particularly manageable challenge.
Localizable technical debt
In “Technical debt in a rail system,” I explored the case of Amtrak’s Acela Express. In that example, I explained that Acela’s passenger cars can tilt to compensate for centrifugal forces that appear when the train rounds curves. The technical debt is in the form of tracks that are too close together to permit the trains to tilt as much as they’re designed to. That limits the trains’ speed rounding curves. The instances of this debt are the curves in which the tracks are too close together. These instances are thus inherently localizable.
In “Debt contagion: how technical debt can create more technical debt,” I described an example in which an organization is unable to upgrade its desktop computers from Windows 8 to Windows 10. In this case, each computer running Windows 8 is an instance of this form of technical debt.
Both of these examples illustrate localizable technical debt. Each instance is self-contained. We can “point” to it as an instance of the debt in question. But localizable technical debt need not be associated with hardware. In software systems, for example, localizable technical debt can exist in a module interface. If interface meets a requirement that’s no longer relevant, it might contain technical debt. That module and any other modules that interact with that interface therefore manifest that technical debt.
Nonlocalizable technical debt
Nonlocalizable technical debt is debt for which the instances are amorphous or system-wide. Or they span the bulk of the system, if not all of it. Retiring nonlocalizable technical debt typically requires extensive reengineering of the assets that manifest it.
For the most part, nonlocalizable technical debt arises at the level of system architecture or above. One can easily imagine this occurring in software systems, where physical constraints have little meaning. But let’s consider a hardware system to illustrate the importance of this concept.
An illustration of nonlocalizable technical debt
Until relatively recently in the United States, most electric power consumers used power for incandescent lamps, heating, or for electric motors. These applications are compatible with an alternating current power distribution system (AC grid). The AC grid is more efficient than an equivalent direct-current architecture (DC grid) when power generation plants are few and relatively distant from power load sites. The efficiency advantage is due to AC’s lower transmission losses compared to DC.
However, advances in electronics and in distributed power generation are eroding the advantages of the AC grid [Dragičević 2016]. Most electronic devices—phones, computers, rechargeable power tools, LED lighting, and electric vehicles—use DC internally. To access the AC grid, they change AC power into DC power, which entails efficiency losses.
Moreover, most renewable power generation systems generate DC inherently. Wind turbines generate AC at a frequency determined by wind power conversion efficiency, but they then convert it to DC before a second conversion to AC at the frequency of the AC grid. And because solar and wind power generators are geographically dispersed, they’re often situated near their load sites. Therefore, the losses due to transmission from generation site to load site are less important than they would be if the generation sites were few, concentrated, and at great distances from the loads they serve.
Our current AC grid architecture is likely to become a net disadvantage in the not-too-distant future. If that happens, we could come to regard the current AC grid as manifesting technical debt. The devices that are designed for the AC grid would also manifest that debt. However, localizing that debt in each device and each component of the AC grid would make little sense. The technical debt in question would reside in the grid architecture, as a whole. It would be inherently nonlocalizable.
Addressing localizable technical debt
As noted above, we can often retire localizable technical debt incrementally—instance-by-instance. In many cases, this enables engineers to address the debt at times and in sequences that are compatible with organizational priorities. By spreading the effort over time, the organization can ensure that costs are within the organization’s capacity in any given fiscal period. This isn’t always possible for localizable technical debt. And engineers are often justifiably averse to the temporary non-uniformity that results from incremental debt retirement. But exploiting localizability when planning debt retirement is often a useful strategy for retiring technical debt economically.
Retiring localizable technical debt incrementally does present some problems. During the retirement process, for any given instance, temporary structures might be necessary to support continued operation with minimal service disruption. For example, with the Acela tracks, an alternate line might serve while the new track installation is in progress. Or the new track might follow a course at some distance from the existing track while trains continue using the existing track. Both approaches require investment beyond the investment required for the new track itself. Some managers have little appetite for such temporary investments. But temporary investments are in a real sense part of the MICs on that debt. They’re unusual in the sense that they’re part of the debt retirement effort, but they’re still MICs. In a way, they’re analogous to the charges that might appear when terminating an auto lease.
Entanglements of different kinds of technical debt
Another consideration when addressing localizable technical debt is its entanglement with other forms of technical debt. With respect to the effort to retire one kind of localizable technical debt, these other forms of technical debt are what I’ve called auxiliary technical debt (ATD). Consider carefully the time order of efforts to retire the localizable technical debt and one or more forms of its ATD. Because retiring localizable technical debt can seem deceptively straightforward, the temptation to deal with it before addressing some of the ATD can be difficult to resist. But dealing with some of the ATD first might actually be the wiser course. For example, when doing so eliminates numerous instances of the localizable technical debt, dealing with the ATD first can produce real savings.
One note of caution
Within the category of localizable technical debt are kinds of debt that are so widespread that retiring them affects a large part of the asset. Each instance of such debt might be identifiable and localized. But the instances are so widespread that they collectively have the properties of nonlocalizable debt. Incremental retirement might still be possible, but a more global retirement effort might be safer and less disruptive.
One approach technologists usually favor is suspending all other work while the debt in question undergoes retirement. While that approach might indeed be safest, all stakeholders must accept and understand the technical issues. And the technologists must understand the concerns of all stakeholders. A joint decision about the retirement strategy among all stakeholders, including technologists, is probably safest.
In the context of debt retirement projects, localizable technical debt provides needed flexibility. Often, the non-uniformity that results from retiring localizable technical debt instance-by-instance can be reduced before the debt retirement project is completed. In the meantime, the team can be relatively free to retire the localizable debt in whichever order is most fitting.
[Dragičević 2016] Tomislav Dragičević, Xiaonan Lu, Juan C. Vasquez, and Josep M. Guerrero. “DC Microgrids–Part II: A Review of Power Architectures, Applications and Standardization Issues,” IEEE Transactions on Power Electronics, vol 31:5, 3528-3549, 2016.
- Retiring technical debt from irreplaceable assets
- Where is the technical debt?
- Auxiliary technical debt: Rules of engagement
- Legacy technical debt retirement decisions
- Controlling incremental technical debt
- Automation-assisted technical debt retirement
- Outsourcing Technical Debt Retirement Projects
- Refactoring for policymakers
- The trap of elegantly stated goals