Using SMART goals for technical debt reduction

Attempting to reduce the enterprise burden of technical debt by setting so-called “SMART goals” in the obvious way can often produce disappointing results. SMART, due to George T. Doran [Doran 1981], is a widely used approach for expressing management goals. “SMART” is an acronym for “Specific, Measurable, Attainable, Realistic, and Time-boxed,” though the last three words (the “ART”) are chosen in various alternative ways. Doran himself used “assignable, realistic, and time-related.”

Prof. George T. Doran (1939-2011), creator of the S.M.A.R.T acronym for setting management objectives
Prof. George T. Doran (1939-2011), creator of the S.M.A.R.T acronym for setting management objectives. Watch a 2010 interview of Prof. Doran at YouTube.
SMART is so embedded in management culture that many assume without investigation that expressing technical debt reduction goals directly using the SMART pattern will produce the desired results. Also embedded in management culture is the aphorism, “You get what you measure.” [Ariely 2010]  [Bouwers 2010] Combining these two ideas in a straightforward way, one might express the technical debt reduction goal as, “Reduce the burden of technical debt by 20% per year for each of the next five years.”

There is ample support for a claim that this “direct” approach to applying the SMART technique will be ineffective. The fundamental issue is that so much of employee behavior affects technical debt indirectly that it overwhelms the effects of employee behaviors that affect technical debt directly. The result is that although the direct approach does cause some employees to adopt desirable behaviors, their impact is not significant enough compared to the effects of the behaviors of employees who see little connection between their own activities and the burden of technical debt, or who are subject to competing constraints on their behaviors that then cause them to act in ways that increase 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 the burden of technical debt by 20% per year 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 at the beginning of the year and the level at the end of the year, presumably 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, periodic goals for total technical debt is not a useful management tool.

Consider a simple example. One form of technical debt—and it’s a common form—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), due to changes in the underlying asset unrelated to the technical debt, or due to debt contagion, or 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, even though the technical debt retirement teams might have been performing perfectly well.

The direct approach assumes a static principal

With most financial debts, the principal amount is specified at the time of loan origination. 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 of those estimates. 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 is not 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.

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 takes into account the timing of MICs. For example, if we know that we must enhance a particular asset by FY21 Q3, and if we know that it bears technical debt that adds to the cost of the enhancement, retiring that debt in FY20 would be advisable. On the other hand, if that form of technical debt has no effect on MICs for the foreseeable future, retiring that technical debt 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 new technical debt—what I call incremental technical debt—technical debt retirement programs might encounter severe difficulty meeting their goals. The technical debt retirement program might simply be unable to keep up with the formation of new technical debt resulting from new development or from ongoing maintenance and enhancement of existing assets.

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 some situations, accepting the debt you’ve incurred—even for the long term—might be called for. Because strict goals about total technical debt can lead to reluctance to incur debt that has a legitimate  business purpose, whatever goals are set 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 express them in ways that are more closely related to behavioral choices. Here are some examples of SMART goals that can be effective elements of the technical debt management program. Some of these examples are admittedly incomplete. For example,  I offer no proof of assignability, attainability, or realism, because they can vary from organization to organization, or because the goal in question must be distributed 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 incremental technical debt can be estimated with relatively high precision. As a goal, it builds on the goal above by requiring that the resources pledged to retire incremental debts actually be expended as intended.

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.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

Other posts in this thread

Zero tolerance and work-to-rule deliveries create an adversarial culture

Last updated on February 1st, 2018 at 07:29 am

Defining technical debt at the level of specificity needed for project objectives is difficult. Confronted with this difficulty, some internal customers of technologists adopt a zero-tolerance approach to technical debt, without specifically defining technical debt. Post-delivery — sometimes much, much, post — when technical debt is discovered or recognized, technologists are held responsible, even in cases when no one could have predicted that a specific artifact would eventually come to be regarded as technical debt. This sets up an adversarial dynamic between technologists and their internal customers.

Delayed or cancelled flights
Trouble at the airport. When airline pilots engage in work-to-rule actions, the immediate result can be large numbers of delayed or cancelled flights. The longer-term result might be beneficial to pilots, the airline, and the public, but only if labor peace can be restored, and the damage to the flying public can be overcome. So it is with work-to-rule deliveries as a way of dealing with zero-tolerance technical debt policies. The organization must overcome the adversarial culture that results from indiscriminate attempts to control technical debt. Technologists do gain some measure of protection by working to rule, but the longer-term benefit of the organization’s learning to manage technical debt arrives only if the adversarial culture can be overcome. Image (cc) Hotelstvedi courtesy Wikimedia.

And that’s when the trouble begins.

Within this adversarial dynamic, technologists try to protect themselves against future recriminations by “working to rule.” They perform only work that is specified by the internal customer. If they find something additional that must be done, they perform that work only if they successfully obtain the customer’s approval. Some customers continue to adhere to a zero-tolerance policy with respect to technical debt, but such a non-specific requirement cannot be met. Because technologists are “working to rule,” they use the ambiguity of the zero-tolerance requirement to assert that they performed all work that was sufficiently specified. This level of performance is analogous to the work-to-rule actions of some employees involved in labor disputes with their employers, and who are literally in compliance with the requirements of the employer, but only literally [LIBCom 2006].

Requiring deliverables to be totally free of technical debt contributes to formation of an adversarial culture, wherein the adversaries are the technologists and their internal customers. Shedding that adversarial culture, once it sets in, can be difficult. Compelling employees, vendors, or contractors to deliver work that’s free of all technical debt is therefore unlikely to succeed. Whether work is performed in-house by employees, or is outsourced, or is performed in-house by contractors, deliverables that meet the minimum possible interpretation of the objectives of the effort are almost certainly burdened with unacceptable levels of technical debt. What can we do to prevent this?

To avoid creating an adversarial culture, we can specify in project objectives some kinds of technical debt that must be removed in toto. To ensure steady progress in technical debt retirement, develop a statement of objectives that includes complete retirement of at least one well-defined class of technical debt, emphasizing debt classes that have the highest anticipated MICs in the near term. Other well-defined classes of technical debt can be addressed on a best-effort basis.

We must accept that any other forms of technical debt that remain at the end of a given project, or any constructions that later come to be recognized as technical debt, are just the “cost of doing business.” We’ll get to them, but unfortunately, not this time.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

Other posts in this thread

Useful projections of MPrin might not be attainable

Last updated on November 28th, 2017 at 11:32 am

SummaryExpect the unexpected with technical debt retirement efforts. Technical debt retirement efforts can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Although these conflicts are technical in nature, resolving them can involve business priorities at any level. Planners must be aware of these potential conflicts, and coordinate with their leaders. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.

For planning purposes, it’s necessary from time to time to project the size of the MPrin for given class of technical debt. The need arises when planning debt retirement, or when preparing debt retirement options for determining resource allocations. Although retiring some kinds of technical debt is straightforward, other kinds of debt can be intertwined with each other. Still others might appear to be easily retired, but actual retirement efforts expose unanticipated entanglements. Moreover, debt retirement efforts can sometimes interact with other debt retirement efforts, operations, maintenance, cyberdefense, and new development in both expected and unexpected ways. For these reasons, making estimates of the MPrin with enough precision to be useful can be notoriously difficult.

A tangle of cordage
A tangle of cordage on board ship. Different kinds of technical debt can be tangled with each other, and untangling them can affect various other engineering efforts. Preparing an asset for a debt retirement effort by doing some preliminary untangling might be wise before trying to estimate the MPrin of any affected class of technical debt.

These considerations rarely arise when planning retirement of financial debts, because money is fungible. We might indeed have other uses for financial resources, but every unit of cash is equivalent to every other. That freedom is not necessarily available when planning resource allocations for technical debt retirement.

For example, not every engineer is equally qualified to address every problem. Some people are particularly capable for certain kinds of work, and not very qualified for other kinds. The problem of scheduling specialists is notorious for generating bottlenecks. And split assignments create even more trouble. People are not fungible.

Planning retirement of a particular set of technical debt classes requires knowledge of any efforts with which that retirement effort might interact. That information might not be available or might not be known. In general, preliminary work to decouple these activities — often called refactoring — can greatly simplify technical debt retirement planning. Even before undertaking refactoring, gathering information about the entanglements of different classes of technical debt can be very helpful. Because allocating resources to such efforts can be difficult in feature-oriented cultures, policymakers can take the lead in raising the priority of such efforts.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

Related posts

How technical debt can create more technical debt

Last updated on November 28th, 2017 at 11:29 am

SummaryAlthough the MPrin of a given class of technical debt can increase or decrease even if instances of that debt remain untouched, the total volume of all other technical debt can change as well. If a class of technical debt is allowed to remain outstanding, its volume can increase as a consequence of seemingly unrelated actions or decisions. Moreover, its existence can cause increases in the volume of other existing classes of technical debt, and its existence can lead to the formation of new classes of technical debt. When formulating technical debt management policy, it's essential to understand these mechanisms and risks

Decisions to defer technical debt retirement must take into account phenomena that, if left unattended, can lead to (a) increasing volume of a given class of technical debt, (b) increasing volume of other existing classes of technical debt, and (c) generating new classes of technical debt. An example can illustrate this behavior.

Suppose Working at a computerwe have a fleet of desktop computers, running a mix of operating systems. A few of these systems are running Windows 8 and the rest are running Windows 10. We’d like to upgrade the Windows 8 machines to Windows 10, but we cannot, because some of their users need access to a (fictional) scriptable application called CRUSH that is not available for Windows 10. CRUSH for Windows 10 is promised “shortly.” Instead of asking our CRUSH users to find an alternative to CRUSH, we defer the Windows 8 upgrade, in the hope that CRUSH for Windows 10 will soon arrive. Meanwhile, other Windows 8 users are happy to continue using Windows 8, and some of them have acquired — and have grown fond of using — another similar (fictional) scriptable package called REMOTE, which is also unavailable for Windows 10. Worse, the CRUSH user community is continuing to grow. Thus, by deferring the Windows 8 upgrade, we have made space for additional problems preventing the upgrade to Windows 10. The technical debt associated with the Windows 8 upgrade now includes Windows 8 itself, and all the scripts, documents, and knowledge that are accumulating for both CRUSH and REMOTE.

The lesson here is not to ban scriptable applications, nor to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The point of the example is merely that deferring debt retirement can enable formation of new instances of existing technical debt (the growth of the CRUSH user community and the assets they continue to develop) and new, unrelated debt (the introduction of REMOTE). Thus, if we make a decision to defer retirement of a class of technical debt, we must consider all costs of such deferment, including expansion of the total volume of technical debt, and all its consequences, as expressed as metaphorical interest charges and MPrin.

Some of the new technical debt that forms when we leave existing debt in place is closely related to the existing debt. For example, once we’ve implemented some part of an asset in a way that we now acknowledge contains a form of technical debt, we tend to apply that same approach when we undertake extensions or enhancements, rather than using what everyone might acknowledge is a superior approach. Martini and Bosch have identified a phenomenon they call debt contagion [Martini 2015], whereby creating new system elements in forms compatible with elements already identified as debt effectively causes debt propagation. This practice helps us maintain some degree of uniformity in the asset, recognizing that in doing so we’re increasing the MPrin of a given class of technical debt. These future expansions of MPrin can be difficult to predict at the time we first incur the debt, or at any time.

However, some forms of technical debt are far less discriminating with respect to the kinds of technical debt they spawn. Debt with this property tends to be associated with the processes used to develop or maintain technical assets. In “A policymaker’s definition of technical debt,” we cite Pugh’s example of acceptance test debt as a form of technical debt [Pugh 2010].

But acceptance test debt can reduce the ability of the organization to retire technical debt. In the absence of automated acceptance tests, testing system components from which technical debt has recently been removed is less efficient and reliable than it would be if automated acceptance tests were available, which retards debt retirement activity and which might even prevent the organization from attempting debt retirement in some circumstances. In a future post, we shall describe how a deficient regime of reviews and inspections can also lead to incurring new technical debt, or to elevated levels of legacy technical debt.

Our final example illustrates how interfaces — which, ironically, were conceived to insulate one portion of an asset from others — can act so as to propagate technical debt. This example could apply to either hardware or software. Given a system S composed of several modules, suppose that module M of S provides services of some kind to several other modules of S. M does contain some technical debt, of a form whose retirement would simplify M’s interface. Because that change would require changes to the modules that use M’s services, retiring the debt has been deferred. Meanwhile, new modules are being introduced into S, and, of course, they must use M’s existing interface. The MPrin of the technical debt associated with M’s interface thus expands.

Unless we provide an alternate version of M (call it M’) or an alternate interface to M, this process of MPrin expansion can repeat whenever new modules are introduced into S. But even if we do provide M’ or an alternate interface to M, engineers must consciously refrain from using the older approaches. Some will refrain, but some might not. Those who are under severe schedule pressure, or those who cannot or will not learn the new approaches, or those who are directed not to use the new approaches, might continue to use the familiar approaches as long as they are able. The MPrin associated with M can thus continue to expand, albeit perhaps at a reduced rate.

Technical debt, left in place, can grow and spawn new forms of technical debt. Make technical debt retirement a priority.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

Related posts

Policy implications of the properties of MPrin

Last updated on November 21st, 2017 at 08:26 am

Formulating sound policy vis-à-vis technical debt requires a thorough understanding of the distinction between the MPrin associated with a technical debt and the principal amount of a financial debt. There are three fundamental differences between them.

MPrin can change spontaneously

For most financial debts, the principal amount is determined by formula, or by voluntary actions of the debtor, such as making periodic payments on an installment loan, or new purchases on a credit card account. By contrast, MPrin can change absent any action by the “borrower.” For example, changes in regulations, standards, or technologies can all cause changes in MPrin. More: “How MPrin can change spontaneously

Technical debt can create more technical debt

Technical debt left in place can create more technical debt without the knowledge or consent of the debtor organization. By contrast, the principal amount of a financial debt can grow, but law or regulation requires notification — and in some cases consent — of the debtor. More: “How MPrin can change spontaneously

Projecting MPrin with useful precision might not be possible

The cost of retiring a technical debt can depend on how the asset bearing the debt has changed over the life of the debt. And it can depend on how the enterprise is engaged at debt retirement time. These factors are difficult to predict. By contrast, projecting the principal amount of a financial debt is formulaic. More: “Useful projections of MPrin might not be attainable

A pole full of wires
A pole full of wires. Technical debt is everywhere.

The policy implications of these properties of MPrin can be profound. The possibility of spontaneous change in MPrin implies a need for investments in market and technological intelligence focused specifically on potential effects on technical debt. The possibility that existing technical debt can cause the creation of new instances of that debt or other debts implies a need for awareness of what kinds of technical debt are most likely to exhibit this phenomenon. Finally, the difficulty of projecting MPrin implies that typical reliance on analytical modeling of enterprise asset evolution in preference to human judgment may be misplaced. A wiser course might be investment in employee retention programs focused on the individuals who can provide the necessary wisdom.

This is just a sketch of the problems policymakers confront when dealing with the properties of MPrin. I’ll be addressing them in more detail in future posts.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

Related posts

Balance technical debt and engineering resources

Last updated on December 27th, 2017 at 03:06 pm

Improving organizational effectiveness in technical debt management — or avoiding incurring new technical debt — should create significant savings, and many competitive advantages. These benefits should arise from the reductions in metaphorical interest charges that result from retiring technical debt. But these benefits become available to the organization only if engineering capacity increases relative to the burdens presented by the remaining reduced levels of technical debt. After the technical debt management program is in place, if the balance between engineering resources and the burdens imposed by the remaining technical debt becomes more favorable, then organizational effectiveness will improve. But if the balance becomes less favorable, as a result of reductions in engineering resources,  organizational effectiveness won’t improve, even at lower levels of technical debt.

Flooding from Hurricane Katrina in New Orleans, 2005.
Flooding from Hurricane Katrina in New Orleans, 2005. Any levee humans can  build can be overtopped or undermined by the forces of Nature. So it is with  technology. Any technology humans can devise to attain mastery over technical debt can be overcome or undermined by organizational policy and organizational politics. To master technical debt, technology is not enough — we must also deal with policy and politics.

Unfortunately, it’s possible to adopt advanced technical debt management practices while at the same time reducing engineering capacity to a level such that engineering effectiveness is no better than it was before the technical debt management program was initiated. The reason for this is that the engineering process is not the sole cause of technical debt. Improving the engineering process to eliminate technical causes of technical debt leaves non-technical causes in place. That’s why technological solutions to the technical debt management problem might not be sufficient to produce benefits in organizational effectiveness and agility.

The focus of research in technical debt management has been on technology — recognition of technical debt, its measurement, representation, retirement, and so on. Progress on improving the engineering process has been significant, especially in software engineering, where a clear “research roadmap” has been developed [Izurieta 2017]. It’s reasonable to assume that effective tools for automating or partially automating technical debt detection and retirement will be widely available and very generally effective in the not-too-distant future, at least for software. But progress has not been confined to debt detection and retirement. Avoiding technical debt formation to the extent possible is much preferable, and in some contexts, it’s practical even today, as Trumler and Paulisch suggest [Trumler 2016].

But it’s also reasonable to ask whether such developments will have much impact on the limiting effects of carrying technical debt, even in software. Given the necessary resources, much of the technical debt now extant could be retired. That is, debt retirement rates are determined only by the will and the capacity to invest in debt retirement. Currently, the levels of will and capacity for such activity are insufficient. But if new methods for managing technical debt become available, one might wonder whether organizations will apply resources sufficient to ensure that they actually experience a reduction in the limiting effects of technical debt.

The open question is this: will technological developments alone suffice to gain control of the problem of technical debt? Perhaps not. Organizations could exploit the advancements in technical debt management to execute reductions in engineering staffing — and therefore cost — while they divert savings to other parts of the enterprise, thereby allowing technical debt to remain at levels that, although much reduced, are nevertheless sufficient to compromise the effectiveness of that reduced engineering staff.

For example, schedule pressure is widely recognized as contributing to technical debt formation and persistence. If engineering groups become more adept at managing and preventing technical debt, but marketing and sales groups do not improve their own intelligence and planning processes and consequently demand new capabilities with even shorter timelines than they now do, the enterprise might not benefit from the new technical debt management capabilities, even though the burden of technical debt has been reduced.

Until we have evidence of significant change in the behavior of non-technologists — or even acknowledgment that their behavior contributes to debt formation — we can expect the effects of non-technical causes of technical debt to persist, and possibly even to grow.

This blog focuses on the non-technical etiology of technical debt formation and persistence, and approaches for managing it. Watch this space.

References

[Ariely 2010] Dan Ariely. “You are what you measure,” Harvard Business Review 88:6, p. 38, 2010.

Available: here; Retrieved: June 4, 2018

Cited in:

[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

Cited in:

[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.

Cited in:

[Izurieta 2017] Clemente Izurieta, Ipek Ozkaya, Carolyn Seaman, and Will Snipes. “Technical Debt: A Research Roadmap: Report on the Eighth Workshop on Managing Technical Debt (MTD 2016),” ACM SIGSOFT Software Engineering Notes, 42(1), 28-31 (2017). doi:10.1145/3041765.3041774

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

Cited in:

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

Cited in:

[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8 (2016). doi:10.1109/MTD.2016.10

Cited in:

Related posts