Retiring localizable technical debt

When technical debt appears as discrete chunks—that is, when it’s localizable—we can often retire the debt incrementally, system-by-system, module-by-module, or even instance-by-instance. These approaches offer great flexibility, both technically and financially, which makes retiring localizable technical debt a particularly manageable challenge.

Localizable technical debt

Electricity pylons, Hamilton Beach, Ontario, Canada
Electricity pylons, Hamilton Beach, Ontario, Canada: a small part of the AC power grid, which seems destined one day to manifest a great deal of non-localizable technical debt. Photo by Ibagli courtesy Wikimedia Commons
Pylons in the same line are visible in Google Street View.

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 are designed to tilt to compensate for centrifugal forces that appear when the train rounds curves. The technical debt is in the form of tracks that were too close together to permit the trains to tilt as much as they’re designed to, which 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 “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 the sorts of technical debt in which the instances are localizable—each instance is self-contained, and 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, which might have been designed to meet a requirement that’s no longer relevant. That module and any other modules that interact with that interface manifest that technical debt.

Non-localizable technical debt

Non-localizable technical debt is debt for which the instances are amorphous or system-wide, or span the bulk of the system, if not all of it. Retiring non-localizable technical debt typically requires extensive re-engineering of the assets that manifest it.

For the most part, non-localizable 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.

Until relatively recently in the United States, most electric power consumers used power for incandescent lamps, heating, or for electric motors in elevators, refrigeration, home appliances, pumps, and so on. 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, because transmission losses are lower for AC than for DC.

However, advances in electronics and in distributed power generation technologies are eroding the advantages of the AC grid [Dragičević 2016]. Most electronic devices, including phones, computers, rechargeable power tools, LED lighting, and electric vehicles use DC internally. To access the AC grid, they use converters that change AC power into DC power, which entails efficiency losses due to the conversion. Moreover, solar power generation systems such as photovoltaics generate DC inherently. Modern 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 the grid requires. And because solar and wind power generators are geographically dispersed, they’re often situated near their load sites, as for example, a photovoltaic array on the roof of a home would be. Therefore, the losses involved in transmission from generation site to load site are much 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 does happen, we could come to regard the current AC grid, and the devices that are designed for it, as manifesting technical 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 non-localizable.

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 and within the organization’s resource capacity in any given fiscal period. Although this isn’t always possible for localizable technical debt, and although engineers are often justifiably averse to the temporary non-uniformity that results from incremental debt retirement, exploiting localizability when planning debt retirement is often a useful strategy for retiring technical debt economically.

Incremental retirement of localizable technical debt does present some problems. During the retirement process, for any given instance, it might be necessary to install temporary structures to enable continued operation with minimal service disruption. For example, with the Acela tracks, an alternate line might be needed while the new track is installed, or the new track might need to be installed at some distance from the existing track while trains continue using the existing track. Either approach requires investment beyond the investment required for the new track itself. Some managers have little appetite for such temporary investments. But they are in a real sense part of the MICs on that debt. They’re unusual, as MICs go, in the sense that they’re incurred as 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.

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 when, for example, doing so eliminates numerous instances of the localizable technical debt.

One note of caution

Within the category of localizable technical debt are some kinds of debt that are so widespread in the asset that retiring them affects a large part of the asset, if not all of the asset. While it’s true that each instance of such debt is identifiable and localized, the instances are so widespread that they collectively have the properties of non-localizable debt as far as retirement efforts are concerned. Incremental retirement might still be possible, but a more global retirement effort might be safer and less disruptive. One approach, usually favored by the technologists, is to suspend 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 recommended.

Last words

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.

Cited in:

Other posts in this thread

Tension between policymakers and technologists

Last updated on July 24th, 2018 at 08:17 pm

Tension between policymakers and technologists, which can manifest as misalignment of their respective priorities, is a significant contributor to uncontrolled growth of technical debt. In this thread I explore sources of this tension and introduce concepts that can assist policymakers and technologists in their efforts to control the growth of technical debt.

Effective, sustainable control of technical debt is the objective of technical debt management policy. In an enterprise that has achieved this objective, technical debt serves as a strategic tool that assists in attaining and maintaining market leadership. In such an organization, technical debt does exist, and some legacy technical debt might remain in place, but technical debt growth is managed strategically, if growth occurs at all. Any technical debt that carries significant MICs, and which compromises productivity and enterprise agility, is addressed and retired with appropriate priority. In short, technical debt is addressed not solely as a technological issue, but as a component of business strategy.

Raindrops on a grapevine
Raindrops on a grapevine. We often think of tension as a negative, destructive force. But tension—in the case of raindrops, surface tension—is what holds a raindrop together. Tension gives the raindrop structure and integrity. The tension between technologists and policymakers can also be constructive. It can ensure that the enterprise manages its technical debt in ways that balance the political imperatives of both technology and strategic health.

This stance is at odds with the historical position most enterprises have adopted vis-à-vis technical debt. Historically, technical debt has been seen as a technical problem, if it has been recognized at all. Most enterprises have left the management of technical debt to the technologists. Frequently, then, the policymaker who enters the discussion about technical debt might be seen by technologists as an interloper, arriving late to the discussion, or as a less-than-knowledgeable invader attempting to seize control of a piece of the technologists’ domain. Tensions can arise between policymakers and technologists. Such tensions complicate the problem of managing technical debt.

One possible source of this tension is revealed in a study of the literature of technical debt, which is evolving so rapidly that it has itself become a focus for research. Li et al. [Li 2015] have produced a review of the software engineering technical debt literature, from which we can extract insights useful to policymakers. Although they studied only the literature relating to technical debt in software engineering, their conclusions are, at least in part, applicable to any field in which the components of the finished product are executed within software tools before being committed to operational form. This covers a wide array of knowledge-intensive endeavors, including mechanical system design, electronic design, framing of legislation, process design, architecture, and even book authorship.

In this thread, I explore the sources of the tension between the modern reality of technical debt as an enterprise issue, and the historical situation of technical debt as a technological issue. This can serve as a guide for policymakers in reframing technical debt from a technological issue dependent for resolution on enterprise resources, to an enterprise issue dependent for resolution on technological resources.


[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.

Cited in:

[Li 2015] Z. Li, P. Avgeriou, and P. Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

Other posts in this thread