Last updated on July 11th, 2021 at 11:07 am
Throughout this blog, I’ve been using the terms legacy technical debt and incremental technical debt. Legacy technical debt is debt that existed before we undertook the current project; incremental technical debt is debt we incurred in the course of executing the current project. But there is some incremental technical debt that’s actually legacy debt incurred intentionally.
Reviewing some terminology
As I’ve defined incremental technical debt, it’s any debt we incur in the course of the current work. That definition works well for most incremental technical debt. For example, if we recognize at the end of the project that we should have done something a bit differently, then we’ve incurred incremental technical debt. This is one of the four forms of technical debt Fowler identifies in his 2x2 technical debt matrix [Fowler 2009].
But we must be a bit more careful, because some incremental technical debt is actually legacy debt incurred intentionally.
Legacy technical debt is debt that we incurred earlier, and which we’ve inherited as part of the asset. Sometimes we’re aware of legacy technical debt; sometimes we haven’t actually realized yet that it is indeed technical debt. In any case, the technical artifacts that comprise the legacy technical debt can impose constraints on new development. Unless we retire the legacy debt, however we modify an asset must be compatible with the unmodified parts of the assets as they are.
Sometimes technical debt can be both legacy and incremental
Although the two kinds of technical debt—legacy and incremental—might seem at first to be mutually exclusive, there’s a subset of legacy technical debt that we incur in the course of executing the current project.
Here’s a physical example:
After the United States Civil War, the state of the U.S. rail system was a bit chaotic. Most of the rail lines in the northeast and western regions of the country used standard gauge rail beds: rails that are 1,435 mm (4 feet 8 1⁄2 inches) apart. Most of the South was using a broader gauge: 1,524 mm (5 feet). These conflicting gauges comprised a legacy technical debt. The combined rail system retired that debt over a two-day period beginning on Monday, May 31, 1886, when all the southern railroads coordinated to convert from a 5-foot gauge to 4 feet 9 inches [Southern Railfan 1966].
In the years immediately before the U.S. rail system retired its legacy debt, expansion or repair of the southern rail network was necessarily compatible with the broader gauge. But the broader gauge was itself legacy technical debt. That new expansion or repair work would thus have comprised newly incurred technical debt that would have also added to the legacy technical debt. Thus, in some situations, some newly incurred technical debt can be legacy technical debt.
Here’s a software example:
A software development team is executing a project to enhance the capabilities of the Marigold product. Marigold is one product in the Garden Flowers personal productivity suite. Unfortunately, the original architecture of Garden Flowers didn’t anticipate the course that the suite has since taken. That architecture now comprises legacy technical debt. However, changing the suite architecture isn’t in the charter of the Marigold team. So they’ll be creating new technical artifacts that are compatible with the current architecture. Someday, some other team will modify or replace what the Marigold team is building now. That will happen when the company revamps or replaces the Garden Flowers architecture. Thus, some of the new technical debt the Marigold team is now incurring will join the legacy technical debt associated with the Garden Flowers architecture.
Moreover, the Marigold team might incur other technical debt in the course of its activities. That might happen if, for example, it fails to complete its task. Or it could happen if the team completes its task in some suboptimal way. In that case it will be incurring incremental technical debt that it probably should retire soon. Thus, in the same project, it would be incurring both (a) purely incremental technical debt, and (b) incremental technical debt that’s also legacy technical debt.
Why legacy debt incurred intentionally matters
Any program of rational technical debt management entails measuring—or at least estimating—the volume of technical debt incurred in the course of executing each project. The goal is to limit the debt incurred, so as to get control of the total technical debt outstanding.
But with legacy technical debt, as in the example above, we can’t always control the debt we incur. In some projects, it’s necessary to incur additional legacy technical debt because the work we do must be compatible with existing assets. We want to limit incremental technical debt, but we can’t always avoid incurring incremental debt that’s also legacy debt.
This distinction is important for both policy formulation and management intervention. For instance, if a team incurs purely non-legacy incremental technical debt, we might want to address it immediately. Or we might commit to addressing it immediately after delivery. Alternatively, suppose we can obtain good data about a particular kind of legacy technical debt that’s growing because of the need to keep new development compatible with existing debt-ridden assets. Then we can use that data to elevate the priority of retiring that legacy debt before it grows even larger.
Last words
So when we ask projects to report their incremental technical debt, we want them to distinguish between legacy debt incurred intentionally, and incremental debt that they incurred for reasons specific to the project. Having data about both kinds of incremental technical debt is a necessity if we want to take appropriate management action to maintain control of the technical debt portfolio.
References
[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.
Available here; Retrieved January 10, 2016.
- Technical debt in software engineering
- Team composition volatility
- How performance management systems can contribute to technical debt
- Unrealistic definition of done
- Spontaneous generation
- Legacy debt incurred intentionally
- Controlling incremental technical debt
- Refactoring for policymakers
[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.
Available: here; Retrieved: July 26, 2018.
Other posts in this thread
- Managing technical debt
- Leverage points for technical debt management
- Undercounting nonexistent debt items
- Crowdsourcing debt identification
- Demodularization can help control technical debt
- Metrics for technical debt management: the basics
- Accounting for technical debt
- Three cognitive biases
- The resilience error and technical debt
- Synergy between the reification error and confirmation bias
- Retiring technical debt can be a wicked problem
- Retiring technical debt can be a super wicked problem
- Degrees of wickedness
- Legacy debt incurred intentionally