Last updated on July 8th, 2021 at 01:06 pm
Attempting to reduce technical debt by setting so-called “SMART goals” in the obvious way can often disappoint. SMART, due to George T. Doran [Doran 1981], is widely used for expressing management goals. “SMART” is an acronym for “Specific, Measurable, Attainable, Realistic, and Time-boxed.” The last three words are available in various alternative ways. Doran himself used “assignable, realistic, and time-related.”
SMART is deeply embedded in management culture. Many assume without investigation that expressing technical debt goals using the SMART pattern will produce desired results. Also embedded in management culture is the aphorism, “You get what you measure.” [Ariely 2010] [Bouwers 2010] A typical technical debt reduction goal: “Reduce technical debt by 20% per year for the next five years.”
SMART goals in their simplest form are ineffective for technical debt
That’s why it’s necessary for management to develop a series of SMART goals that affect behaviors that have indirect effects on technical debt. In the first part of this post, “Setting a direct SMART goal for technical debt reduction is problematic,” I explore the problems inherent in the direct approach. In the second part, “How to set SMART goals for technical debt,” I provide examples of SMART goals that touch on behaviors that have indirect effects on technical debt.
Setting a direct SMART goal for technical debt reduction is problematic
Let’s begin by exploring some of the problems with the direct approach. In this section, I assume that management has set a SMART goal for the enterprise in the form, “Reduce technical debt by 20% for each of the next five years.” But there’s nothing special about the numbers. My comments below apply to the form of the goal, rather than the specific numbers.
The direct approach assumes measurability
To attain a goal of a 20% reduction in technical debt in a given year, we must be able to measure the level of technical debt. We measure it at the beginning of the year and at the end of the year. Presumably we do so with confidence in the 90% range or better. Such a measurement with the precision required might not be possible. Moreover, in most cases the probability that such a measurement is possible is low. For these reasons, setting periodic goals for total technical debt isn’t a useful management tool.
Consider a simple example. One common form of technical debt is missing or incompletely implemented capability. In some instances, the metaphorical principal (MPrin) of a given instance of this debt in the current year can change spontaneously to a dramatically larger value in the following year (or even the following week). This can happen due to changes in the underlying asset unrelated to the technical debt. Ot it can happen due to debt contagion. Or it can happen due to any number of other reasons. When this happens, the technical debt retirement effort for that year can appear to have suffered a serious setback. Setbacks like this can happen even though the technical debt retirement teams have been performing perfectly well.
The direct approach assumes a static principal
With most financial debts, a loan agreement sets the principal amount. Moreover, we can compute the principal at any time given the mathematical formulas specified in the loan agreement.
By contrast, in many cases, the metaphorical principal amount of a technical debt might be neither fixed nor readily computable. We can estimate the MPrin of a given kind of technical debt at a given time, and we can even make forward projections. But they are merely estimates, and their error bars can be enormous. See “Policy implications of the properties of MPrin” and “Useful projections of MPrin might not be attainable.”
The direct approach focuses on MPrin, not MICs
Objectives expressed in terms of the volume of technical debt—the total MPrin—are at risk of missing the point. Total MPrin isn’t what matters most. What matters is MICs—the total cost of carrying the debt. Even more important is the timing of arrival of the MICs. See “The Principal Principle: Focus on MICs.”
And like MPrin, MICs can vary in wild and unpredictable ways. For example, the MICs for a piece of technical debt borne by an asset that isn’t undergoing maintenance or enhancement can be zero; in a later time period, when that asset is undergoing enhancement, the MICs can be very high indeed. See “MICs on technical debt can be unpredictable” for a detailed discussion.
Priority setting for technical debt retirement is most effective when it accounts for the timing of MICs. For example, suppose we know that we must enhance a particular asset by FY21 Q3. And suppose we know that it bears technical debt that adds to the cost of the enhancement. Then retiring that debt in FY20 would be advisable. But if that technical debt has zero MICs for the foreseeable future, retiring it might not be worth the effort.
The direct approach fails to distinguish legacy technical debt from incremental technical debt
Unless policies are already in place governing the formation of incremental technical debt, technical debt retirement programs might encounter severe difficulty. New development and maintenance and enhancement of existing assets are ongoing. They generally produce technical debt in various forms. The technical debt retirement program might simply be unable to keep up with new debt formation.
The direct approach fails to anticipate the formation of enterprise-exogenous technical debt
Technical debt can sometimes form as a result of innovations, changes in standards, or changes in regulations that occur entirely external to the enterprise. I call such technical debt enterprise-exogenous. When this happens, the technical debt retirement effort can appear to have suffered a serious setback, even though the technical debt retirement teams might have been performing perfectly well. Before initiating a technical debt reduction program, it’s wise to first deploy a program that’s capable of retiring technical debt at a pace that at least equals the pace of formation of enterprise-exogenous technical debt.
Incurring technical debt is sometimes the responsible thing to do
At times, incurring technical debt is prudent. In these situations, accepting the debt you’ve incurred—even for the long term—might be appropriate. Strict goals about total technical debt can lead to reluctance to incur debt that has a legitimate business purpose. To prevent this, goals for total technical debt must be nuanced enough to deal with these situations. Goals for total technical debt that adhere strictly to the SMART goal pattern sometimes lack the necessary level of nuance.
How to set SMART goals for technical debt
SMART goals can work for technical debt management, but we must relate them to behavioral choices. Here are some examples of SMART goals that can be effective elements of a technical debt management program. Some of these examples are admittedly incomplete. For example, I offer no proof of assignability, attainability, or realism. Such attributes can vary from organization to organization. And we must allocate the goal in question across multiple organizational elements in ways peculiar to the organization.
At least 30% of incremental technical debt will be secured technical debt at the end of Year 1; 60% by the end of Year 2
Incremental technical debt is technical debt that’s incurred in the course of work currently underway or just recently completed. Because it’s so well understood, its MPrin can be estimated with higher precision than is usually possible with legacy technical debt. That precision is needed for defining the collateral and resources used to secure the debt.
A secured technical debt, like a secured financial debt, is one for which the enterprise reserves the resources needed to retire the debt. However, unlike a financial debt, the resources required to retire a technical debt might not be purely financial. Beyond financial resources, they might include particular staff, equipment, test beds, and downtime. The commitment might extend beyond the current fiscal period. Secured technical debt is a powerful means of driving down total technical debt burden, but it might require modification of internal budget management processes and fiscal reporting. Policymakers can help in designing and deploying the necessary changes.
Within one year, at least 50% of all incremental technical debt will be retired within one year of its origination; 70% within 18 months
This goal also exploits the fact that we can estimate incremental technical debt with relatively high precision. As a goal, it builds on the goal above by requiring that the organization actually expend as intended the resources pledged to retire incremental debts.
Within one year, all engineers and their direct supervisors will be educated in basic technical debt concepts
The educational materials will be developed in the next five months and piloted with 10% of the technical staff within seven months. The material will include an online proficiency test that 90% of engineers will have successfully passed within a year.
Within one year, 90% of project plans will include projections of the MPrin of the incremental technical debt they expect to generate for each delivery cycle
This information is useful for making forward projections of resources needed to secure incremental technical debt. Tracking the accuracy of these projections helps project planners improve their estimates.
Within one year, initiate a practice of identifying the top five forms of legacy technical debt, ranked by the volume of the contagion
Debt contagion is the propagation of a given form of technical debt by creating new system elements or assets in forms compatible with elements already identified as technical debt. By examining the body of incremental technical debt created enterprise-wide in a given time period (say, by fiscal quarter), we can determine the portion of that incremental debt that results from contagion, for each type of contagious legacy technical debt. This data is needed to identify the most contagious forms of legacy technical debt. They are prime candidates for debt retirement.
Within one year, initiate an industrial intelligence practice that is responsible for projecting the formation of enterprise-exogenous technical debt
This group must have a sophisticated grasp of the technologies in use within the enterprise that already bear enterprise-exogenous technical debt, or which could be subject to the formation of enterprise-exogenous technical debt. Its responsibilities cover enterprise products and services, as well as enterprise infrastructure. It issues advisories as needed, and an annual forecast. The group is also responsible for recommending and monitoring participation in industrial standards organizations. The group reports to the CIO or CTO.
References
[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.
This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018
[Bouwers 2010] Eric Bouwers, Joost Visser, and Arie van Deursen. “Getting What You Measure: Four common pitfalls in using software metrics for project management,” ACM Queue 10: 50-56, 2012.
Available: here; Retrieved: June 4, 2018
[Doran 1981] George T. Doran. “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives”, Management Review, 70:11, pp. 35-36, 1981.
