Last updated on July 16th, 2021 at 05:08 pm
As noted earlier, a technical debt retirement project (DRP) emphasizes retiring a particular kind or kinds of technical debt from a set of assets. But those assets might also carry other kinds of technical debt. With respect to a given DRP, we can regard this other technical debt as Auxiliary Technical Debt (ATD). Because the presence of ATD can defocus debt retirement projects, it presents a risk we must anticipate and mitigate.
A word of caution
One word of caution. The technical debt discussed in this post is assumed to be localizable. Localizable technical debt is technical debt that manifests itself as discrete chunks. Each instance is self-contained, and we can “point” to it as an instance of the debt in question. More: “Retiring localizable technical debt”
Mitigating the risks associated with the auxiliary technical debt
This post explores concepts and approaches for mitigating the risks associated with the auxiliary technical debt (ATD) of a given debt retirement project (DRP). As might already be evident, these initialisms (ATD, DRP, and one more to come) can be difficult to keep straight. Here’s a quick guide:
- T always means Technical
- D always means Debt or Design
- R always means Retirement
- P always means Project
So, DRP is Debt Retirement Project.
Also, if you have a pointing device, you can hover the cursor over the first mention of each initialism in each section. Then your browser displays the expansion of the initialism. Touch screen users and keyboarders: sorry, I haven’t yet figured out how to help you in an analogous way, so let me know if you have an idea.
I’ve been using the term TDIQ—Technical Debt In Question—to denote the kinds of technical debt whose retirement is the objective of a given DRP. The ATD of that DRP, then, is the collection of instances of any other kinds of technical debt. That is, all types differing from the TDIQ of the DRP, and which are present in the assets being modified by the DRP. Notice that the property of being auxiliary technical debt is relative. It’s relative to the objectives of a given DRP. A particular instance of technical debt might be ATD for one DRP, and TDIQ for another DRP, depending on the respective objectives of each DRP. Notice also that the ATD of a given DRP can include several different kinds of technical debt.The temptation to retire auxiliary technical debt
Let’s now examine a scenario in which ATD can generate risk for a DRP. In this scenario, we’ll consider only one kind of ATD; call it ATD0.
Suppose several members of the DRP team undertake work to retire the DRP’s TDIQ in a portion of one of the debt-bearing assets. In performing this work, they encounter some instances of ATD0. Studying these instances of ATD0 carefully, they devise a plan. They realize that “fixing” the ATD0 along with the TDIQ in that portion of the asset would be easier and less risky than amore focused approach. The more focused approach would be to leave the ATD0 in place and attend only to the TDIQ. Let’s call the approach they adopted the ATD approach. And let’s say that the TDIQ approach is one in which the team addresses only the TDIQ. It leaves in place the ATD0 and all other ATD it finds.
Compared to the TDIQ approach, the advantages of the ATD approach are fairly clear. After the work is complete, in either approach, the team must test and re-certify the asset. In the TDIQ approach, when a subsequent DRP tries to retire ATD0, that second DRP team will need to test and re-certify the asset again. In the ATD approach, we can avoid modifying, re-testing, and re-certifying the asset a second time. We can avoid it because we’ve already retired all instances of ATD0 from the asset. Thus, in the ATD approach we can avoid a second round of modification, testing, and re-certification.
Risks associated with retiring auxiliary technical debt
But the ATD approach also has some serious disadvantages.
Enterprise assets might be left in a mixed state
Unless the team plans to retire all instances of ATD0, then upon completion of the DRP, enterprise assets will be in a mixed state. Some will be free of both the TDIQ and ATD0; some will be free of the TDIQ but continue to harbor ATD0. This non-uniformity can create complications for subsequent maintenance, documentation, testing, training, enhancement, automation assisted development, and so on.
Complications in testing and re-certification
If test results for the modified assets indicate the possibility of new defects, the cause might be associated with the TDIQ work, or the ATD work, or both. Resolving any issues in the test results is thus more complicated under the ATD approach than it is under the TDIQ approach. Similar considerations affect re-certification. Thus, there is a risk that the ATD approach will complicate interpretation of test and re-certification results.
Questions about the reliability of technical debt inventory data
As noted in an earlier post, for any given DRP, the DRP team needs to know which assets bear that project’s TDIQ. In the TDIQ approach, any data previously or concurrently gathered about the location of instances of ATD0 remains valid. It maintains its validity because the TDIQ approach doesn’t retire any instances of ATD0. However, in the ATD approach, such inventory data must be corrected to account for the retirement of whatever instances of ATD0 are retired in the ATD approach. Thus, there are problems if ATD0 inventory data has already been collected, or if it’s being collected in parallel with the DRP. The DRP team must then take steps to adjust the inventory data regarding locations of ATD0 as it retires instances of it.
There is one minor exception to this claim about TDIQ’s validity-preserving qualities. In some instances, retiring an instance of TDIQ can incidentally retire an instance of ATD0. It happens.
There is of course a risk that this will not occur as needed. If that risk materializes, it can create problems for any subsequent DRP for which the ATD0 is contained in its TDIQ. This can be especially challenging if there are multiple DRPs in process simultaneously. Suppose each DRP is working on different TDIQs, potentially in different debt-bearing assets. If they all encounter and retire instances of ATD0, keeping the inventory current can be a complicated affair.
Unconstrained scope creep
Suppose there is a DRP whose objective is retiring its TDIQ. And suppose it has decided to also retire instances of a particular kind of ATD, say ATD0. Although that activity would represent an expansion of scope beyond retiring the TDIQ, it might be acceptable and it might even be prudent. But as the team undertakes to retire ATD0, it might confront a similar problem. That problem relates to the relationship between the ATD0 and yet another kind of ATD, which we might call ATD1. The DRP team might then decide to expand scope again. And so on. In general, there is no self-evident stopping point for such a chain of scope expansion. In these circumstances, scope creep can become an unmitigated risk, threatening the coherence and focus of the DRP, with consequences for its budget and schedule.
Last words
In some cases, some of the ATD might be so intertwined with the TDIQ that retiring some instances of the TDIQ necessarily retires some of the ATD. And in other cases, leaving the ATD in place severely complicates retiring the TDIQ. In still other cases, leaving the ATD in place leaves the assets in a complex state that makes ongoing maintenance or enhancement work more difficult. In these cases, what I called the ATD approach above is plainly the wiser course, compared to the TDIQ approach.
Policymakers have a role to play here. They can develop guidance for DRP teams to apply as they come upon these difficult situations. That guidance can help them decide whether to take the ATD approach or the TDIQ approach. The military calls this guidance “rules of engagement,” while politicians call it “guardrails.”
Deciding between the ATD and TDIQ approaches on a whim, or on what feels right at the moment, inevitably leads to a chaos of inconsistency and scope creep. The safest course is to adopt wise rules of engagement. Then adjust them as the organization learns more about retiring technical debt from its assets.
Other posts in this thread
- Retiring technical debt from irreplaceable assets
- Where is the technical debt?
- Legacy technical debt retirement decisions
- Retiring localizable technical debt
- Controlling incremental technical debt
- Automation-assisted technical debt retirement
- Outsourcing Technical Debt Retirement Projects
- Refactoring for policymakers
- The trap of elegantly stated goals