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.
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, we’ve incurred incremental technical debt. This is one of the four forms of technical debt identified by Fowler 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 was 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 any new development. Unless we retire the legacy debt, however we modify an asset must be compatible with 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 can be incurred 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 what is called standard gauge rail beds: rails that are separated by 1,435 mm (4 ft 8 1⁄2 in). Most of the South was using a broader gauge: 1,524 mm (5 ft). These conflicting gauges comprised a legacy technical debt. The debt was finally retired 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 legacy debt was retired, any expansion or repair of the southern rail network that was compatible with the broader gauge, which was about to be retired, would have added to — or maintained — the legacy technical debt. It 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 engaged in a project to enhance the capabilities of the Marigold product, which is one product in the Garden Flowers personal productivity suite. Unfortunately, the original architecture of the suite didn’t anticipate the course that the suite has since taken, and it now comprises legacy technical debt. However, because changing the suite architecture isn’t in the charter of the Marigold enhancement team, they’ll be creating new technical artifacts that are compatible with the current architecture, but which will someday be modified or replaced when the Garden Flowers architecture is revamped or replaced. Thus, some of the new technical debt now being incurred by the Marigold team will be added to 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, if, for example, it fails to complete its task, or completes it in some suboptimal way. In that case it will be incurring incremental technical debt that it probably should retire soon after (if not before) delivery of the Marigold enhancements. 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 formation and management intervention. For instance, if purely non-legacy incremental technical debt is incurred, we might want to address it immediately, or perhaps commit to addressing it immediately after delivery. Alternatively, if 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, we can use that data to elevate the priority of retiring the legacy debt before it grows even larger.
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 was 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.
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
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