Last updated on January 10th, 2020 at 07:26 pm
For organizations, an elegantly stated goal is one that’s so clearly stated that anyone can understand it, remember it, and recite it to others. An example for technical debt management might be, “We’ll drive enterprise technical debt to zero over five years.” Or, “No project is finished if it increases the total volume of technical debt.” But when the goal pertains to solving a problem for which all solutions are messy, stating that goal elegantly risks becoming ensnared in what I call the trap of elegantly stated goals.
Because elegant goal statements are so memorable and so repeatable, elegantly stated goals spread rapidly, especially if they’re even a bit inspirational. But elegantly stated goals become traps when they incorporate overly simplistic views of how to attain those goals.
And that often happens when technical debt is involved. Here are four guidelines that can help organizations avoid the trap of elegantly stated goals for technical debt.
Beware the halo effect
The halo effect [Thorndike 1920] is a cognitive bias [Kahneman 2011] that systematically skews our assessments of the qualities of a person, product, brand, company, or any entity, really. If our sense of one quality of the entity is positive, we’re more likely to assess as positive other qualities of that entity. Thus, the elegance of a goal statement can cause us to regard the goal as more desirable than we would if the goal were stated less elegantly. For example, the statement, “we will achieve zero technical debt in five years,” can increase the chances that we’ll believe that achieving such a goal is attainable. Indeed, some might not even question its desirability, let alone its attainability.
When devising goals for technical debt management, beware the halo effect. Always question desirability, taking costs and benefits into account.
Technical debt matters less than its metaphorical interest charges
The metaphorical interest charges (MICs) on technical debt, rather than the metaphorical principal (MPrin) of the debt itself, are what matter. A goal for total technical debt might be more elegant and more simply stated than would be a goal for technical debts that carry high MICs. But goals for total technical debt can lead to effort spent on debts with low MICs. And those efforts produce little benefit.
When setting goals for technical debt management, pay attention to the MICs. Distinguish between low-MICs and high-MICs technical debt. Keep in mind that MICs can fluctuate. One kind of technical debt can be a low priority at one point in time, and a high priority at another.
Controlling technical debt is safer than trying to drive it to zero
Blind application of an elegantly stated goal can have strikingly silly unintended consequences. Keep in mind that the policymaker’s definition of technical debt is any technological element that contributes, through its existence or through its absence, to lower productivity, or depressed velocity, or a higher probability of defects.
Consider this example of strikingly silly unintended consequences for the goal of zero technical debt. An engineer creates an innovative and superior solution to a previously solved problem. Existing assets that incorporate the old solution are instantly outmoded by the innovative solution. Those existing assets now carry technical debt. If the enterprise directive mandates zero technical debt, some engineering managers might be tempted to do the unexpected. They might inhibit the kind of creativity that leads to innovative solutions to previously solved problems. The temptation arises because introducing those new solutions creates exogenous technical debt in existing assets. Therein lies the trap of the elegantly stated goal.
Throttling efforts to find innovative solutions to previously solved problems is one example of an unintended consequence of trying to drive technical debt to zero. Controlling technical debt is probably a safer option than trying to drive it to zero. With respect to technical debt, it would be wise to study the possible unintended consequences of elegantly stated goals before propagating those goals.
Get control of the behaviors that lead to technical debt
Technical debt management efforts typically emphasize technical debt retirement or engineering process improvement. While both activities are worthwhile, the root causes of the technical debt problem often lie elsewhere. See, for example, the thread in this blog exploring nontechnical precursors of technical debt.
For example, “across the board” cuts to project budgets can lead to technical debt formation as teams suspend efforts that would have already created technical artifacts. Indeed, those teams might even lack the resources necessary to retract any partially implemented capabilities. See “How budget depletion leads to technical debt” for a more detailed explanation of this particular technical debt formation mechanism.
Such budget control tactics as across-the-board cuts can be counter-effective unless they attend to their technical debt implications. When budget control tactics lead to technical debt formation, they can add to future expenses through the MICs on the debt they generate. Those additional expenses then create future needs for budget cuts, creating a vicious cycle. To gain control of technical debt, we must alter these budget control tactics. We need to provide teams with the resources they need for retracting partial implementations. That would ensure that budget reductions don’t lead to technical debt formation.
Investing in technical debt retirement and engineering process improvement without first addressing the nontechnical causes of technical debt is probably futile. It’s like bailing out a sinking rowboat without first plugging its leaks. The stated goal, “We’ll drive technical debt to zero in five years,” might better be replaced with, “Within two years we’ll get control of the behaviors that lead to technical debt.”
The template known as SMART goals provides one approach to setting goals with limited exposure to the risk of elegantly stated goals. See “Using SMART goals for technical debt reduction,” for details.
Achieving control of technical debt—rather than attaining any particular level of technical debt—is a useful goal. Either we will control technical debt or technical debt will control us.
- Unrealistic optimism: the planning fallacy and the n-person prisoner's dilemma
- Confirmation bias and technical debt
- Retiring technical debt in irreplaceable assets
- Technical debt retirement: where is the technical debt?
- Rules of engagement for auxiliary 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