The trap of elegantly stated goals

Last updated on July 10th, 2021 at 11:16 am

Rock cairns in a wilderness area
Rock cairns—also known as rock stacks—in a wilderness area. Some rock stacks in parks and wilderness areas serve a practical purpose as trail markers. But in recent decades, rock stacking has become a fad. Rock stacks aren’t permanent—they use no glue, rings, or fasteners—but their presence does degrade the experience of Nature. The practice continues, in part, because many find the elegance of the structures appealing. As with rock stacks, the elegance of elegantly stated goals has a dark side.

For organizations, an elegantly stated goal is one that anyone can understand, remember, and recite to others. An example for technical debt management is, “We’ll drive technical debt to zero over five years.” Or, “No project is finished if it increases technical debt.” But when the goal relates to solving a problem that has only messy solutions, 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 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]. It 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. 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’ll achieve zero technical debt in five years,” can increase the chances that we’ll believe that 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. Before adopting elegantly stated goals for technical debt, it would be wise to be aware of their possible unintended consequences.

Get control of the behaviors that lead to technical debt

Technical debt management efforts typically emphasize debt retirement or engineering process improvement. While both activities are worthwhile, the root causes of technical debt often lie beyond engineering. See, for example, the thread in this blog exploring nontechnical precursors of technical debt.

For example, across-the-board budget cuts can lead to technical debt. This happens because teams suspend efforts that have already created technical artifacts. If those teams lack resources needed for retracting partially implemented capabilities, the partial implementations remain in place. See “How budget depletion leads to technical debt” for a more detailed explanation of this technical debt formation mechanism.

Budget control tactics like across-the-board cuts can be counter-effective. If they don’t attend to their technical debt implications, they can add to future expenses through the MICs on the debt they generate. They can thus create future needs for budget cuts, and that leads to 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.

Investments in technical debt retirement and engineering process improvement are worthwhile. But they can be futile unless we first address the nontechnical causes of technical debt. 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, “We’ll get control of the behaviors that lead to technical debt within two years.”

Last words

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’ll control technical debt or technical debt will control us.

References

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Accounting for technical debt

Last updated on July 11th, 2021 at 04:57 pm

Accounting for technical debt isn’t the same as measuring it
Accounting for technical debt isn’t the same as measuring it. We usually regard our accounting system as a way of measuring and tracking enterprise financial attributes. We think of those financial attributes as representations of money. Technical debt is different. It isn’t real, and it isn’t a representation of money. It’s a representation of resources. Money is just one of those resources. Money is required to retire technical debt. We use money when we carry technical debt, and when we retire it. But we also use other kinds of resources when we do these things. Sometimes we forget this when we account for technical debt.

We need a high-caliber discussion of accounting for technical debt [Conroy 2012]. It’s a bit puzzling why there’s so little talk of it in the financial community. Perhaps one reason for this is the social gulf between the financial community and the technologist community. But another possibility is the set of pressures compelling technologists to leave technical debt in place and move on to other tasks.

Here’s an example. One common form of technical debt is the kind first described by Cunningham [Cunningham 1992]. Essentially, when we complete a project, we often find that we’ve advanced our understanding of what we actually needed to reach our goals. Because of our advanced understanding, we recognize that we should have taken a different approach. Fowler described this kind of technical debt as, “Now we know how we should have done it.” [Fowler 2009] At this point, typically, we disband the team and move on to other things, leaving the technical debt outstanding, and often, undocumented and soon to be forgotten.

Echo releases and management decision-making

A (potentially) lower-cost approach involves immediately retiring the debt and re-releasing the improved asset. I call this an “echo release.” An echo release is one in which the asset no longer carries the technical debt we just incurred and immediately retired. But echo releases usually offer no immediate, evident advantage to the people and assets that interact with the asset in question. That’s why decision makers have difficulty allocating resources to echo releases.

This problem arises, in part, from the effects of a what I regard as a shortcoming in management accounting systems. Most enterprise management accounting systems track effectively the immediate costs associated with technical debt retirement projects. They do a much less effective job of representing the effects of failing to execute echo releases, or failing to execute debt retirement projects in general. The probable cause of this deficiency is the distributed nature of the MICs—the metaphorical interest charges associated with carrying a particular technical debt. MICs appear in multiple forms: lower productivity, increased time-to-market, lost market share, elevated turnover of technologists, and more (see “MICs on technical debt can be difficult to measure”). Enterprise accounting systems don’t generally represent these phenomena very well.

The cost of not accounting for the cost of not retiring technical debt

Decision makers then adopt the same bias that afflicts the accounting system. In their deliberations regarding resource allocation, they emphasize only the cost of debt retirement. These discussions usually omit from consideration altogether any mention of the cost of not retiring the debt. That cost can be enormous, because it is a continuously recurring periodic charge with no end date. Those costs are the costs of not accounting for the cost of not retiring technical debt.

If we do make long-term or intermediate-term projections of MICs or costs related to echo releases, we do so to evaluate proposals for retiring the debt. Methods vary from proposal to proposal. Few organizations have standard methods for making these projections. And lacking a standard method, comparing the benefits of different debt retirement proposals is difficult. This ambiguity and variability further encourages decision makers to base decisions solely on current costs, omitting consideration of projected future benefits.

Dealing with accounting for technical debt

Relative to technical debt, the accounting practice perhaps most notable for its absence is accounting for outstanding technical debts as liabilities. We do recognize outstanding financial debt. But few balance sheets mention outstanding technical debt. Ignorance of the liabilities outstanding technical debt represents creates an impression that the enterprise has capacity that it doesn’t actually have. That’s why tracking our technical debts as liabilities would alleviate many of the problems associated with high levels of technical debt.

But other shortcomings in accounting practices can create additional problems almost as severe.

Addressing the technical-debt-related shortcomings of accounting systems requires adopting enterprise-standard patterns for debt retirement proposals. Such standards would make possible meaningful comparisons between different technical debt retirement options and between technical debt retirement options and development or maintenance options. One area merits focused and immediate attention: estimating MPrin and estimating MICs.

Standards for estimating MPrin are essential for estimating the cost of retiring technical debt. Likewise, standards for estimating MICs, at least in the short term, are essential for estimating the cost of not retiring technical debt. Because both MPrin and MICs can include contributions from almost any enterprise component, merely determining where to look for contributions to MPrin or MICs can be a complex task. So developing a checklist of potential contributions can help proposal writers develop a more complete and consistent picture of the MICs or MPrin associated with a technical debt. Below are three suggestions of broad areas worthy of close examination.

Revenue stream disruption

Technical debt can disrupt revenue streams either in the course of retirement projects, or when defects in production systems need attention. When those systems are out of production for repairs or testing, revenue capture might undergo short disruptions. Technical debt can extend those disruptions or increase their frequency.

For example, a technical debt consisting of the absence of an automated test can lengthen a disruption while the system undergoes manual tests. Technical debt consisting of misalignment between the testing and production environments can allow defects to slip through. Undetected defects can create new disruptions. Even a short disruption of a high-volume revenue stream can be expensive.

In advance of any debt retirement effort, we can identify some associations between classes of technical debt and certain revenue streams. This knowledge is helpful in estimating the contributions to MICs or MPrin from revenue stream disruption.

Extended time-to-market

Although technologists are keenly aware of productivity effects of technical debt, these effects can be small compared to the costs of extended time-to-market. In the presence of outstanding technical debt, time-to-market expands not only as a result of productivity reduction, but also from resource shortages and resource contention. Extended time-to-market can lead to delays in realizing revenue potential. And it can cause persistent and irreparable reductions in market share. To facilitate comparisons between different technical debt retirement proposals, estimates of these effects are invaluable.

Data flow disruption

All data flow disruptions aren’t created equal. Some data flow processes can detect their own disruptions and backfill as needed. For these flows, the main contribution to MICs or MPrin is delay. And the most expensive of these are delays in receiving or processing orders. Less significant but still important are delays in responding to anomalous conditions. Data flows that cannot detect disruptions are usually less critical. But they nevertheless have costs too. All of these consequences can be modeled and estimated. We can develop standard packages for doing so. And we can apply them repeatedly to MICs or MPrin estimates for different kinds of technical debt.

Last words

Estimates of MICs or MPrin are helpful in estimating the costs of retiring technical debt. They’re also helpful in estimating the costs of not retiring technical debt. In either case, they’re only estimates. They have error bars and confidence limits. The accounting systems we now use have no error bars. That, too, is a shortcoming that must be addressed.

References

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Leverage points for technical debt management

Last updated on July 10th, 2021 at 07:17 am

McMurdo Station, Antarctica, as seen from nearby Observation Hill
McMurdo Station, Antarctica, as seen from nearby Observation Hill. The United States Antarctic Program, a unit of the National Science Foundation, operates the station. It can house as many as 1258 people in Summer. Photo (cc) Gaelen Marsden courtesy McMurdo Station in Antarctica.

Adopting a technical debt management programs entails significant organizational change. The problem can seem so daunting that we don’t know where to begin. The places to begin are the places where the change agents have greatest leverage—what systems analysts call leverage points. Consider this scenario:

You’re sitting in the kickoff meeting of the new Technical Debt Management Task Force. The CEO is talking about how she realized that the company had a technical debt problem. It was when the Marigold project went through delay after delay, and was finally declared done, with multiple objectives waived. She’s saying something about, “we were trying to do backflips with millstones around our necks. So I want this task force to show us how to get rid of the millstones, and then get rid of them.”

OK, you think. But how? We’re a global enterprise with thousands of engineers and operations on every continent. Except maybe Antarctica. No wait, we’re there, too. McMurdo I think. We have software we don’t even know much about, acquired long ago along with the companies that built it. And we’re building new systems or modifying old ones all the time, trying to move everything to the cloud while enhancing data security. Where do we begin to look for the millstones of technical debt?

Have you been in that meeting? If not, can you imagine being in that meeting? Meetings like that are happening around the globe. We’re all in the same soup.

Leverage points: how to get rid of the millstones

It turns out that the answers to the millstone questions are available, but the pioneers and deep thinkers who have shown the way aren’t working on technical debt. Their field is called systems analysis. They work on problems like the collapse of the North Atlantic fishery, urban deterioration, unemployment, poverty, climate change, and the causes of the Great Recession of 2008—really difficult problems. Although the technical debt problem isn’t quite that challenging, it’s challenging enough to justify taking a look at the methods of systems analysis.

And when we do that, we immediately encounter a concept many call leverage points.

What are leverage points?

Leverage points are places in complex systems where a small change in one thing can produce big changes in system behavior. In a brilliant 1997 article, Donella Meadows describes what she calls “places to intervene in a system.” [Meadows 1997] She followed this article, making improvements each time, in 1999 [Meadows 1999] and 2008 [Meadows 2008]. Let me summarize Meadows’ work here.

To alter the behavior of a complex system, intervene at one or more of 12 categories of leverage points. For example, one category is called “Rules.” It consists of the incentives, punishments, and constraints that govern the behavior of the people and institutions that comprise the system. By adjusting the system’s rules, we can alter overall system behavior.

One more thing: the leverage points form an ordered hierarchy, ordered by effectiveness. Acting at a higher-level leverage point is more effective than acting at a lower-level leverage point. And more difficult, too. The ordering of the categories is a bit fuzzy, because every situation has its own quirks, but generally, the order is as given in the list below.

The twelve leverage points

In a moment I’ll give an example of using leverage point #9, Delays, to bring about change in the way the enterprise deals with technical debt. But first, here’s a brief summary of the leverage points in increasing order of leverage; not enough to truly understand what they are, but probably enough to pique your interest. As I write posts that illustrate interventions at these leverage points, I’ll link to them from here.

  1. Numbers: Constants and parameters such as subsidies, taxes, and standards
  2. Buffers: The sizes of stabilizing stocks relative to their flows
  3. Stock-and-Flow Structures: Physical systems and their nodes of intersection
  4. Delays in feedback loops
  5. Balancing Feedback Loops: The strength of the feedbacks relative to the impacts they are trying to correct
  6. Reinforcing Feedback Loops: The strength of the gain of driving loops
  7. Information Flows:  The structure of who does and does not have access to information
  8. Rules: Incentives, punishments, and constraints
  9. Self-Organization: The power to add, change, or evolve system structure
  10. Goals: The purpose or function of the system
  11. Paradigms: The mind-set out of which the system—its goals, structure, rules, delays, parameters—arises
  12. Transcending Paradigms

Delays in feedback loops

When we use feedback to control systems, and there are delays in the feedback, we can potentially create destructive system behavior. And that can happen when we try to control technical debt.

Whenever we try to control a quantity in an enterprise process, we must (a) set a target value for that quantity; then (b) measure its current value; and then (c) take action as appropriate to move the current value toward the target value. Systems analysts (and control theorists) call that arrangement a feedback loop. The action taken to move the current value to the target value is sometimes called the control signal. Under certain conditions, the feedback works as expected.

For example, to control the profitability of the enterprise, we can examine its net income, say, quarterly. And at the end of each quarter we can make adjustments if net income isn’t in the target range.

Feedback loops generally work pretty well, but under some conditions, oscillations can develop. One of those troublesome situations occurs when there’s a delay in the loop that’s of the same order as (or longer than) the time the system takes to respond to adjustments. Meadows uses the example of adjusting the water temperature of a shower when there’s a long delay between making the adjustment and feeling its effects. Overcorrection is almost inevitable, and that’s what causes system oscillation.

How controlling technical debt can create feedback loops

So let’s suppose that we’re trying to control the rate of accumulation of technical debt. One approach is to set a target for TDnew, the new technical debt generated in a project. To be fair to all projects, we decide to normalize this quantity according to the project budget B. So we set targets for each project’s N = TDnew/B, and we require that projects estimate N, on an ongoing basis, with a goal of having N in some target range when the project is complete.

Identifying technical debt isn’t straightforward

One problem with this approach is that we rarely identify accurately all the technical debt we’ve incurred until some time has passed after project delivery. With time, as the newly produced assets go into production and learning accumulates, we acquire the wisdom needed to identify more of the technical debt we created. This is one source of delay in this feedback loop.

So let’s assume that this happens for several projects, and management decides that delayed recognition of incurred technical debt is a common occurrence. To account for this, management lowers the target ranges for N for future projects. This causes project managers and project sponsors to include in their project plans additional effort directed at retiring more of their incremental technical debt before their projects complete, to enable them to project lower values of N. They must therefore identify as much of the incremental technical debt as they can, and retire it, to meet the lower targets for N.

How oscillations set in

But recall that technical debt identification sometimes requires time and experience using the newly produced asset. And the reverse process also occurs. Technical artifacts that we thought were technical debt prove to be useful in unexpected ways, and actually turn out not to be debt items after all. As a result, some of the incremental technical debt that got retired before the project was completed actually should not have been retired. Eventually, people realize that this happens with uncomfortable frequency, and so the targets for N are raised once more.

Oscillations thus set in. Long delays inevitably cause them. To prevent oscillations, shorten the delays.

How to shorten delays in feedback controlling technical debt

When we use feedback to control a system, delays in that feedback can lead to instability. Trying to control technical debt is no exception. With technical debt we can shorten delays in several ways.

  • If the asset is meant for human use, involve representatives of the user population in the development and design process as soon as practical. Have them exercise the asset, or prototypes, early. Listen to their suggestions. Observe how they use the asset.
  • If the asset must interact with non-human assets, exercise it early and often. Don’t think of this as testing, though it might look very much like testing. What you’re actually doing is searching for shortcomings in how the asset interacts with non-human assets, in design and implementation in an asset that already works.
  • Subject the asset to multiple reviews all along the development trajectory. Don’t wait for final release to review it.

These practices expose technical debt items early—potentially, during initial design—thereby reducing delays in identifying what is and what isn’t technical debt. They help to advance the date at which we uncover missing capabilities or capabilities designed or implemented in awkward ways. No surprise, I’m sure, but these practices are consistent with Agile approaches to technological development.

Indirect effects can add to delayed recognition of technical debt

Most of the argument above assumed that the incremental technical debt associated with the project was incurred within the asset undergoing development or maintenance. But technical debt can occur in other assets as well. When the development team is unaware of such “remote” or “indirect” incremental technical debt, recognition of that new incremental technical debt can be significantly delayed. The project’s N (the ratio of incremental technical debt to project budget) will appear to be smaller that it actually is, until that remote incremental technical debt is recognized.

This form of delay is likely to occur when the debt incurred is asset-exogenous. Recall the example of line extension of mobile phones. In that example, the enterprise incurs technical debt in one set of products as a result of the introduction of a different product. In some cases, the newly incurred technical debt is immediately evident. When it is not, delays can be substantial.

This effect is by no means rare. Any organizational change can potentially add to the technical debt portfolio—reorganizations, acquisitions, expansions, wholly new products, and much more.

Last words

Interventions at the leverage points of an organization can produce the changes we want with a minimum of effort. Some subtlety is involved, because Meadows’ leverage points are expressed at a high level of abstraction.  But applying them to the problem of technical debt management is a promising approach.

Bookmark this post. I’ll be linking to more examples of using leverage points to manage technical debt. So far:

References

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Technical debt use disorder

Last updated on July 11th, 2021 at 09:53 am

A ball and chain, with shackle
A ball and chain, with shackle. Attaching this device to the legs of prisoners or slaves limits their ability to run. Similarly, technical debt limits the organization’s ability to exploit new opportunities, or even to maintain their current market positions.

The American Psychiatric Association (APA) has identified a disorder called Substance Use Disorder (SUD). It includes alcoholism, drug addiction, and other patterns related to substance use [APA 2013]. Their research can serve as a model for understanding organizational behavior related to technical debt. In this post I show how to use that model to describe a disorder of organizations that we could call Technical Debt Use Disorder (TDUD). In the grip of TDUD, the organization can’t retire much of its technical debt. It can’t stop incurring new debt, even though almost everyone in the organization realizes that technical debt is harming the organization.

A brief description of APA’s publication, DSM-5®, might explain the connection between SUD and TDUD. DSM-5 is the fifth revision of the Diagnostic and Statistical Manual of Mental Disorders (DSM). Health care professionals in the United States and much of the rest of the world use it as a guide to diagnosing mental disorders. It’s also a framework for further research. First published in 1952, the current revision, DSM-5, was released in 2013.

The connection to technical debt

So what does DSM-5 have to do with technical debt?

What distinguishes responsible use of technical debt from irresponsible use is a topic that has generated many papers, conference presentations, and hallway debates over the years. Although there is consensus about the distinction in many cases, the debate continues. Sometimes, though, research in one field suggests paths forward in seemingly unrelated fields. So much thought and study has been invested in DSM-5 that it’s worth a look to see if the technical debt community can harvest something useful from the research in psychiatry.

I looked at DSM because I noticed that organizations that carry significant volumes of technical debt seem to have difficulty retiring it. In some cases, they also have difficulty halting accumulation of technical debt, or even slowing the rate of accumulation. This struck me as similar to the substance use problems some people encounter. I began to wonder whether there might be parallels between the substance use disorders that afflict people—alcoholism, drug addiction, and so on—and the technical debt problems that afflict organizations.

In the table below is one set of parallels I’ve found. The left column of the table is the list of diagnostic criteria for Substance Use Disorder provided in the DSM. The right column is my rewording of those criteria in an attempt to make them apply to how organizations deal with technical debt. I had thought initially that the rewording exercise might be difficult—that it might be a stretch. And here and there, it was a bit of a stretch. But overall, the SUD framework is a very good fit.

Diagnosing technical debt use disorder

Have a look at the table, and then check out the comments below it about how health care professions use the criteria.

DSM-5 Criteria for Substance Use Disorder (SUD)Criteria for Enterprise Technical Debt Use Disorder (TDUD)
1. Taking the substance in larger amounts or for longer than you’re meant to.
1. Incurring technical debt in larger amounts than you intended and carrying it for longer than you intended.
2. Wanting to cut down or stop using the substance but not managing to.2. Wanting to retire your technical debt or reduce the rate of incurring it but not managing to.
3. Spending a lot of time getting, using, or recovering from use of the substance.3. Spending a lot of time dealing with the consequences of the technical debt you’ve already incurred.
4. Cravings and urges to use the substance.4. Insistent demands on precious resources, causing the enterprise to incur “just a little more” technical debt.
5. Not managing to do what you should at work, home, or school because of substance use.5. Not managing to attend to the needs of existing products, services, or technological infra­structure because of the demands resulting from metaphorical interest charges on technical debt.
6. Continuing to use, even when it causes problems in relationships.6. Continuing to carry technical debt, or continuing to incur yet more technical debt, even though it causes toxic conflict among employees, and problems in customer relationships and strategic partnerships.
7. Giving up important social, occupational, or recreational activities because of substance use.7. Giving up developing important new products or services, or upgrading critical infrastructure, or pursuing new initiatives because of resource deficits traceable to technical debt service.
8. Using substances again and again, even when it puts you in danger.8. Incurring technical debt again and again, even when it puts the enterprise in fiscal danger or danger of losing market position.
9. Continuing to use, even when you know you have a physical or psychological problem that could have been caused or made worse by the substance.9. Continuing to incur technical debt, even when you know you have a fiscal or market leadership problem that could have been caused or made worse by technical debt.
10. Needing more of the substance to get the effect you want (tolerance).10. Needing to incur more technical debt to get the fiscal effect you need—a product delivered or a contract completed.
11. Development of withdrawal symptoms, which can be relieved by taking more of the substance.11. Upon attempting to retire existing technical debt, or halting incurring yet more technical debt, fiscal or market position problems develop in short order, which can be relieved only by incurring yet more debt.

In health care, two or three symptoms indicate a mild substance use disorder; four or five symptoms indicate a moderate substance use disorder, and six or more symptoms indicate a severe substance use disorder. Have a look at the right-hand column. How would you score your organization? Can we categorize the severity of an organization’s problem with technical debt using a scale similar to the one health care professionals use for SUD?

Conclusion

Technical debt isn’t inherently evil. Its existence among technological assets isn’t proof of engineering malpractice. For example, we can decide responsibly to deliver a system that carries technical debt. But if we do, we must carefully weigh the consequences of incurring that debt against the consequences of delayed delivery. And we must have a workable plan for retiring that debt, or for carrying the burden of its MICs.

But organizations can nevertheless trap themselves in cycles of technical debt, unable to make much progress in reducing it. In some cases, business as usual won’t work. In some cases, only drastic action can break the cycle.

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Technical debt smell

Last updated on July 7th, 2021 at 05:16 pm

“The Young Chief Uncas,” 1869 chromolithograph by John Mix Stanley (1814–1872)
“The Young Chief Uncas,” 1869 chromolithograph by John Mix Stanley (1814–1872). Photo courtesy Wikimedia Commons.
Uncas then deduces amazing details about the man who left the track he examined—150 years ahead of Sherlock Holmes. Natty Bumppo, Cooper’s Hawkeye character, calls the signs Uncas uses tell-tales.

Technical debt smell would be a useful indicator of the presence of a severe problem of technical debt in an organization. Unfortunately, technical debt doesn’t usually have a smell, as such. But metaphorically, it might have indirect indicators, just as we might say, “I smell a rat” when probing a mystery. Actually, the idea of indirect indicators has a long and storied tradition. In one scene midway through James Fenimore Cooper’s The Last of the Mohicans, Uncas (who is the actual last of the Mohicans) demonstrates his tracking skills [Cooper 1857]:

The young Mohican bent over the track, and removing the scattered leaves from around the place, he examined it with much of that sort of scrutiny that a money-dealer, in these days of pecuniary doubts, would bestow on a suspected due-bill. At length he arose from his knees, satisfied with the result of the examination.

Tell-tales in Nature

Nature abounds with examples of such skill at noticing tell-tales. Lions, tigers, bears, and all sorts of fauna use their olfactory senses to detect food, predators, mates, offspring, weather, and even the change of seasons. Smell gives them access to information they need, often before sight or hearing can.

That’s probably a part of why smell has become a useful metaphor in software engineering. The technical literature about code smells is vast and growing [Haque 2018]. In a blog post titled “CodeSmell,” Martin Fowler defines code smell as, “…a surface indication that usually corresponds to a deeper problem in the system.” [Fowler 2006] Code smells are traits that are easy to recognize, and often—but not always—indicators of problems.

Enter the “red flag”

The concept is also useful in the business domain, though there we use a different metaphor and a different term. In the business context, we call smells red flags. Investopedia defines a red flag as, “…an indicator of potential problems with a security, such as any undesirable characteristic that stands out to an analyst as it pertains to a company’s stock, financial statements or negative news reports.” But I’ve heard the term red flag used in the context of evaluating proposals, assessments, status reports, personnel, and intelligence of all kinds.

Whether called tell-tales, smells, red flags, or just indicators, their value is that they suggest the outlines of something we haven’t yet seen clearly enough to identify with certainty. Their principal attributes are that they’re available at the surface of the domain we’re surveying, they’re relatively cheap to obtain, and, if found, they suggest trouble, and deeper investigation might be worthwhile.

Cultural smells

In the software engineering community, technical debt is regarded as a smell that indicates trouble in the system’s software. So we might ask, “Among policymakers, what are the smells that indicate trouble in the organization?” If technical debt is the trouble we’re looking for, what are the cultural smells that indicate that technical debt might be a problem?

Said differently, can we find, or can we develop, a set of attributes of enterprise culture that indicate the degree of severity of an organization’s problems with technical debt?

Here are some possible “technical debt smells”—aspects of enterprise culture that could indicate problems with technical debt:

  • There is a general belief that technical debt afflicts some organizations, but not ours
  • We’re a new startup—just a year old—so we have no technical debt.
  • We don’t build software, therefore no technical debt
  • Nontechnical members of our executive team have little if any knowledge of the concept of technical debt
  • No enterprise resources are allocated to educating nontechnical employees about technical debt
  • The VP of Marketing doesn’t believe that anything she does could possibly contribute to technical debt
  • There is a general belief that if we have technical debt, it’s due solely to malpractice on the part of engineers
  • We’ve tried to assess the total cost of eliminating all of our technical debt. But we found the estimates so unreliable that we decided to leave well enough alone.
  • We do believe that technical debt does have costs. But because it only affects the productivity of engineers, we just hired more engineers and decided to live with it.

Last words

Clearly we could assemble a list of technical debt smells—beliefs about technical debt and behaviors that affect it—and check for their presence in a given organization. But fortunately, some of that work has already been done, albeit in a very different context; That context is a malady psychiatrists call “Substance Use Disorder.” More about that next time.

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

Cited in:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Using SMART goals for technical debt reduction

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

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.
There’s ample support for a claim that applying the SMART technique in direct ways will be ineffective. Much employee behavior affects technical debt indirectly. It can overwhelm the effects of employee behaviors that affect technical debt indirectly. The direct approach does cause some employees to adopt desirable behaviors. But their impact isn’t significant enough compared to the effects of the behaviors that affect technical debt indirectly. Employees who see little connection between their own activities and the burden of technical debt can unwittingly have enormous impact. Moreover, many 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 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

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[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

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:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

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:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Exogenous technical debt

Last updated on July 9th, 2021 at 04:58 pm

Exogenous technical debt is debt that arises from causes not directly related to the asset that bears the debt. Mastering understanding of exogenous technical debt is essential to controlling technical debt formation. Exogenous technical debt is particularly troublesome to those who work on the affected assets. They can’t control its formation, and they’re rarely responsible for creating it. But their internal customers and those who control resources often fail to understand this. Indeed, those who work on the affected assets often bear blame for the formation of exogenous technical debt even though they had no role in its formation, and could have done nothing to prevent its formation.

Exogenous technical debt and endogenous technical debt

Technical debt is exogenous when it’s brought about by an activity not directly related to the assets in which the debt appears. The word exogenous comes from the Greek exo– (outside) + –genous (related to producing). So exogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that don’t involve the asset directly.

Why we must track exogenous technical debt

Asbestos with muscovite.
Asbestos with muscovite. Asbestos is a family of minerals occurring naturally in fibrous form. The fibers are all known carcinogens. Until 1990, asbestos was a common ingredient of building materials, including insulation, plaster, and drywall joint compound. It’s now banned, but it’s present in existing homes and offices. The ban caused these structures to incur exogenous technical debt. Photo by Aramgutang courtesy Wikipedia.

Because so much technical debt arises indirectly, controlling its direct formation is insufficient to achieve control. To control technical debt formation, we must track which activities produce it. We must track both direct and indirect effects. Allocating technical debt retirement costs to the activities that brought that debt about is useful. It’s useful even if the allocation doesn’t affect budget authority for those activities. Knowledge about which past activities created technical debt, and how much, is helpful for long-term reduction in the rate of technical debt formation.

When we think of technical debt, we tend to think of activities that produce it relatively directly. We often imagine it as resulting solely from engineering activity, or from decisions not to undertake engineering activity. In either case the activity involved, whether undertaken or not, is activity directly involving the asset that carries—or which will be carrying—the technical debt. This kind of technical debt is endogenous technical debt. The word endogenous comes from the Greek endo– (within or inside) + –genous (related to producing). So endogenous technical debt is that portion of an asset’s debt that comes about from activities or decisions that directly involve the asset.

More about endogenous technical debt in future posts. For now, let’s look more closely at exogenous technical debt, and its policy implications.

Examples of exogenous technical debt

In “Spontaneous generation,” I examined one scenario in which technical debt formation occurs spontaneously—that is, in the absence of engineering activity. Specifically, I noted how the emergence of the HTML5 standard led to the formation of technical debt in some (if not all) existing Web sites. This happened because those sites didn’t exploit capabilities that had become available in HTML5. Moreover, some sites needed rehabilitation to remove emulations of the capabilities of the new standard. Those emulations needed to be replaced with use of facilities in the HTML5 standard. All of these artifacts—including those that existed, and those that didn’t—comprised technical debt. This scenario thus led to the formation of exogenous technical debt.

In a second example, AMUFC, A Made-Up Fictitious Corporation, incurs technical debt when the vendor that supplies the operating system (OS) for AMUFC’s desktop computers announces the date of the end of extended support for the version of the OS in use at AMUFC. Because the end of extended support brings an end to security updates, AMUFC must retire that debt by migrating to the next version of that vendor’s OS before extended support actually ends.

In both examples, the forces that lead to formation of exogenous technical debt are external to the enterprise and the enterprise’s assets. But what makes technical debt exogenous is that the forces that led to its formation are unrelated the engineering work being performed on the asset. This restriction is loose enough to also include technical debt that arises from any change or activity external to the asset, but within the enterprise.

Exogenous technical debt arising from actions within the enterprise

Exogenous technical debt can arise from activities or decisions that take place entirely within the enterprise.

For example, consider the line of mobile devices of AMUFC (A Made-Up Fictitious Corporation). Until this past year, AMUFC has been developing ever more capable devices. These efforts extended its line of offerings at the high end—the more expensive and capable members of the line. But this past quarter, AMUFC developed a low-end member of the line.

As often happens, price constraints for the low-cost device led to innovations. Those innovations could produce considerable savings in manufacturing costs if used all across the line. In effect, the designs of the previously developed higher-end models have incurred exogenous technical debt. The debt is exogenous because the activity that led to debt formation wasn’t performed on the assets that carry the debt. The debt is real, even though the activity that led to debt formation occurred within the enterprise. This kind of exogenous technical debt is asset-exogenous. Exogenous technical debt of the kind that results from activity beyond the enterprise is enterprise-exogenous.

Exogeneity versus endogeneity

For asset-exogenous technical debt, ambiguity between endogeneity and exogeneity can arise. The example above regarding the line of mobile devices produced by AMUFC provides an illustration.

For convenience, call the team that developed one of the high-end devices Team High. Call the team that developed the low-end device Team Low. From the perspective of Team High, the technical debt due to the innovations discovered by Team Low is exogenous. But from the perspective of the VP Mobile Devices, that same technical debt might be regarded as endogenous. The debt can be endogenous at VP level because it’s possible to regard the entire product line as a single asset, and that might actually be the preferred perspective of VP Mobile Devices.

This ambiguity can lead to some nasty toxic conflict. Team High and VP Mobile Devices might attack each other as they try to defend themselves proactively against claims that they are incurring technical debt. Avoiding this kind of conflict requires educating everyone as to the origins of technical debt.

Exogeneity and legacy technical debt

The technical debt portfolio of a given asset can contain a mix a technical debt that arose from various past incidents. In assessing the condition of the asset, it’s useful to distinguish this existing debt from debt that’s incurred as a consequence of any current activity or decisions. Call this pre-existing technical debt legacy technical debt.

The legacy technical debt an asset carries is technical debt associated with the asset, and which existed in any form before undertaking work on that asset. For example, consider planning a project to renovate the hallways and common areas of a high-rise apartment building. Suppose workers discover beneath the existing carpeting a layer of asbestos floor tile. Then Management might decide to remove the tile. In this context, we can regard the floor tile as legacy technical debt. It isn’t directly related to the objectives of the current renovation. But removing it will enhance the safety of future renovations. It will also enable certification of the building as asbestos-free, increase the property value, and reduce the cost of eventual demolition. In this situation asbestos removal is retirement of legacy technical debt. Accounting for it as part of the common-area renovation would be misleading.

Exogeneity is relevant when allocating resources for legacy technical debt retirement efforts. If the debt in question is enterprise-exogenous, we can justifiably budget the effort from enterprise-level accounts. For other cases, other resources become relevant, depending on what actions created the debt. For example, suppose that the technical debt arose from a change in enterprise standards. Then we can justifiably allocate retirement costs to the standard-setting initiative. If the exogenous technical debt arose from innovations in other members of the asset’s product line, we can can justifiably allocate those debt retirement costs to the product line.

Policy insights

Understanding the properties of exogenous technical debt can be a foundation for policy innovations that enhance enterprise agility.

Culture transformation

Widespread understanding of the distinction between exogenous and endogenous technical debt is helpful in controlling interpersonal conflict. For example, it can reduce blaming behavior that targets the engineering teams responsible for developing and maintaining technological assets.

Understanding asset-exogenous technical debt helps non-engineers understand how their actions and decisions can lead to technical debt formation. The concept clarifies the import of their actions even when there is no apparent direct connection between those actions or decisions and the assets in question.

Resource allocation

Data about the technical debt creation effects of enterprise activities is helpful in allocating technical debt retirement costs. For example, suppose that we know all the implications of reorganization, including its impact on internal data about the enterprise itself. Then we can charge data-related activity to the reorganization instead of to general accounts of the Information Technology function. This helps the enterprise understand the true costs of reorganization.

Similarly, data about enterprise-exogenous technical debt helps planners understand how to deploy resources to gather external intelligence about trends that can affect internal assets. Such data is also useful for setting levels of support and participation in industrial standards organizations or in lobbying government officials.

Last words

Knowing the formation history of exogenous technical debt provides useful guidance for those charged with allocating the costs of retiring technical debt or preventing its formation.

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[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

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:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

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:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Adopt an enterprise-wide definition of technical debt

Last updated on July 9th, 2021 at 11:25 am

Because effective technical debt management requires cooperation from almost everyone, an enterprise-wide definition of technical debt is essential. Absent a shared definition of technical debt, controversy can develop. Controversy is especially likely among those who have previously encountered the concept—namely, among technologists. Policymakers can make invaluable contributions to the design of the cultural transformation that will enable control of technical debt.

A physical expression of shared commitment, essential to adopting an enterprise-wide definition of technical debt
A physical expression of shared commitment. Effective technical debt management requires both a shared understanding of what it is and a shared commitment to do what’s required to control it.

Li et al. [Li 2015] found that defining what is and what isn’t technical debt remains an open question in software engineering. Even if we restrict the discussion to software constructed in-house, opinions about what constitutes technical debt do differ. The authors found that in the literature of technical debt, “The term ‘debt’ has been used in different ways by different people, which leads to ambiguous interpretation of the term.”

This finding is perhaps the most significant for policymakers. It suggests that controlling technical debt might require forging an organizational consensus about the meaning of the term technical debt. The people of most organizations come from many different backgrounds. Those with little knowledge of technical debt have few preconceptions. But those who are aware of the issue probably interpret the term technical debt in a variety of ways. Because some of those who do have awareness of the term are likely to have strong opinions about its meaning, one can anticipate a need to resolve these differences.

The effect of an absence of standards

Some technical terms, like RAID, byte, compiler, and kilowatt, have widely accepted standard definitions. Although the term technical debt has found wide use, it has no standard definition. What some people categorize as technical debt, others do not. Those who are accustomed to working with terms that have precise, widely accepted definitions might tend to assume that the term technical debt does have (or should have) one as well. This assumption can create some difficulty for people who don’t realize that others might have differing views of the definition of the term.

For example, there are those who believe that defects are not technical debt. And some believe that no element of a technological asset can constitute technical debt unless it is part of a product that a customer uses. Our definition differs with both of these views.

Last words

Policymakers must be aware that there is a lack of consensus about the definition of technical debt. Our definition, crafted specially for the use of policymakers, might seem unusually broad to technologists and engineers. For that reason alone, it’s advisable to become familiar with the various ways technologists use the term. Understanding their perspective is essential to formulating sound policy deserving of their respect.

Other posts in this thread

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[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

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:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

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:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Cultural debt can be the primary driver of technical debt

Last updated on July 17th, 2021 at 06:53 am

Cultural debt can be expensive. Like technical debt, it can incur ongoing metaphorical interest charges (MICs). Schein defines organizational culture as “…a pattern of shared basic assumptions learned by a group as it solved its problems of external adaptation and internal integration…” [Schein 2016]. Following the concept of technical debt, we can regard as cultural debt the subset of shared basic assumptions comprising enterprise culture that are no longer fitting for enterprise realities. We can also include as cultural debt any assumptions that ought to be shared, but which are missing or are only partially shared. And we can include shared assumptions that conflict with each other and need to be resolved.

An example of cultural debt: the term “IT”

A tape measure calibrated in both feet/inches and meters/centimeters
A tape measure calibrated in both feet/inches and meters/centimeters. We can regard the need to possess tools that serve both measurement systems as the metaphorical interest charges on a technical debt. The debt is the result of failing to retire the older “English” system. But from another perspective, the debt involved is actually cultural. Retiring the older system would truly involve a cultural shift.
For most modern enterprises, an element of cultural debt is the very term ITinformation technology. Coined in 1958 by Leavitt and Whisler [Leavitt 1958], the term was then appropriate. It was apt up to about 20 years ago. Until then, the role of IT was primarily management, storage, retrieval, manipulation, and presentation of information. Although those functions remain relevant, the responsibilities of IT have expanded dramatically since then. In many organizations, IT is now responsible for designing, implementing, and maintaining the communication infrastructure. That infrastructure includes Internet access, personal computers, networking, Web presence, telephones, video conferencing equipment, and television.

The modern role of communication

Communication plays a critical and strategic role. An essential element for success is a clear understanding of what IT does and what it contributes. Regarding IT as the “information technology” function of the enterprise therefore risks overlooking and undervaluing these more recently acquired responsibilities. And since the IT function is no longer solely responsible for enterprise information, using the name “IT” or the term information technology risks overvaluing the role of the IT organization relative to information management, while undervaluing its role relative to communications.

In Schein’s culture framework, the term IT reflects a shared assumption about IT’s role. That assumption is that IT is responsible for information. Unfortunately, that assumption is no longer well aligned to the reality of IT’s role. We can regard this misalignment as a cultural debt.

The consequences of cultural debt

The consequences of this particular kind of cultural debt can be severe. For instance, IT is typically responsible for selecting and configuring software for personal computers (PCs). This responsibility can arise as a consequence of two shared assumptions. First is the assumption that computers process information, and second, that IT is responsible for technology-based information processing. The result is that the person who uses the computer doesn’t make all decisions about what many regard as a “personal” computers. When the IT decision differs from the personal preferences of the computer user, we can find conflict.

Worse, a centralized decision process for determining PC configurations is likely to produce outcomes less suitable than would a process more focused at the individual level. That adds to the frustrations of PC users, and exacerbates the conflict between them and IT. To mitigate the risk that some PC users might circumvent IT policy, IT must take steps to prevent such actions. We can regard all of that activity, on the part of both IT and the PC users, as metaphorical interest charges on cultural debt.

An example of retiring cultural debt

In 1987, Edward Yourdon founded a magazine then known as American Programmer. In 1990, Cutter Information Corporation purchased the rights to American Programmer and created Cutter IT Journal. That name includes the term IT. At the time, IT was more suitable than the term programmer. As noted above, the term IT, while once useful and apt, is now outmoded at best and often misleading. Just as the functional name IT in organizations constitutes cultural debt, so it does in the name of a journal.

So in the autumn of 2016, Cutter IT Journal retired the cultural debt in its name, and became Cutter Business Technology Journal. Journals rarely change their names. When they do, the impact of the journal is temporarily depressed. The reduction in impact is due to the split of citations between the former title and the new title. That effect lasts for about two years or so [Tempest 2005]. But as research fields change, their journals must keep pace. Evidently Cutter felt a significant need to retire its cultural debt—significant enough to justify a temporary reduction in impact.

What about cultural debt retirement in companies?

Difficulties associated with retiring cultural debt depend strongly on both the nature of the culture and the nature of the debt. To provide insight into these issues, let’s continue with our exploration of the term IT and its cultural implications.

In many organizations, IT reports to a Chief Information Officer (CIO). Associated with this official’s title are some of the same cultural debts we find for the name “IT”. First, CIOs aren’t the only officers with information management responsibility. Second, many CIOs have responsibilities that transcend information management. Their responsibilities include, for example, the communication infrastructure. Unlike other peer titles such as CEO, CFO, CMO, and COO, the CIO title evokes separation from business-oriented decisions. That separation contributes to a cultural wall between “IT” and “the business.”

The view of IT as an information-centric service organization is perhaps a remnant of the 20th century. Cultures that have this view can become problematic for the organization. The problem is that they tend to regard IT as a source of expense to be minimized, rather than as a strategic partner [Ross 2000]. Still, trends toward strategic acceptance of IT are favorable, according to recent surveys of CIOs [CIO 2018].

The reality is that business technology must contribute to formulation and implementation of enterprise strategy. But some CIOs and their organizations are viewed as separate from “the business.” This limits their ability to help shape enterprise strategy. But it also subjects them to cultural assumptions about their responsibilities that in some instances conflict with each other. That’s a significant source of the metaphorical interest charges on the cultural debt.

One way out of this cultural debt

One possible way to retire this debt might entail retitling Chief Information Officer to Chief Business Technology Officer (CBTO). That’s precisely what happened at Forrester Research in 2011 [Plant 2014].

Unfortunately, the name CBTO conflicts with the three-word pattern of enterprise officer titles (C*O), which might create an urge to name the office Chief Technology Officer (CTO). But that role usually has responsibility for the functions that create technological products or services. Thus, for many organizations, to create a CBTO where there is already a CTO might create further sources of conflict. Using the CTO designation for the CBTO is probably impractical.

But we must find some way to retire this particular cultural debt, because it’s such an effective generator of technical debt. CBTO seems to be the best available path.

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[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

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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

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:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

[Schein 2016] Edgar H. Schein. Organizational Culture and Leadership, Fifth Edition, San Francisco: Jossey-Bass, 2016.

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18, 57–62, 2005.

Available: here; Retrieved: April 5, 2018

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

The Broken Windows theory of technical debt is broken

Last updated on July 8th, 2021 at 05:27 pm

Broken windows in an old abandoned factory
Broken windows in an old abandoned factory. To work in an environment dominated by properties like this must certainly be demoralizing. But whether existing technical debt actually causes people to make choices that incur new technical debt is another question. At this point, it’s an open question.

In the United States, the Broken Windows theory of crime control first appeared in the public conversation in 1982. Kelling and Wilson described it in The Atlantic (then known as The Atlantic Monthly) [Kelling 1982]. Briefly, the theory suggests that in urban environments, we can prevent serious crime by taking some simple steps. They include applying police resources to preventing small crimes such as vandalism, public drinking, and toll jumping. These measures create an atmosphere of order and lawfulness. Gladwell popularized the idea in his explosive best seller The Tipping Point [Gladwell 2000].

In the year before Gladwell’s work appeared, Hunt and Thomas incorporated the Broken Windows theory into their work, The Pragmatic Programmer. They suggest it as a justification for the importance of retiring technical debt immediately upon discovering it [Hunt 1999]. Briefly, the theory as applied to technical debt in software is that tolerating low quality and technical debt in a given asset encourages further degradation of quality and additional technical debt. Within the software community, the Broken Windows theory of managing technical debt is widely accepted [Note a].

Skepticism about the Broken Windows Theory

However, between Kelling’s work in 1982 and the work of Hunt and Thomas in 1999, something happened in criminology. Criminologists and sociologists had become skeptical of the Broken Windows theory as applied to crime prevention. As far back as 1998, investigations had begun to cast doubt on the Broken Windows theory [Harcourt 1998]. In 2006, Eck and Maguire assembled a review of the escalating controversy [Eck 2006].

Meanwhile, O’Brien, Sampson, and Winship, analyzing “big data,” failed to produce strong evidence of the theory’s validity. They did find a weak positive correlation between social orderliness and lawful behavior [O’Brien 2015]. But their research also showed a strong positive correlation between private violent behavior and major crimes. Others noted that what appeared to be positive results for the application of Broken Windows to crime prevention in the 1990s was actually explainable by other phenomena [Note b].

Social scientists and criminologists have taken these findings seriously enough to have founded the Center for Evidence-Based Crime Policy at George Mason University. The Center maintains an evidence-based policing matrix to assist law enforcement organizations in evaluating the validity of claims about the efficacy of specific tactics and strategies. (See their review of Broken Windows Policing.)

The software engineering community is less skeptical

But even as doubts developed about the efficacy of Broken Windows policing for crime prevention, Broken Windows continued to find adherents in the software community. Software researchers continued to regard the theory as pertinent to managing technical debt in software. The software engineering community thus finds itself, perhaps, in the same position with respect to Broken Windows as it is with respect to the Tragedy of the Commons. Broken Windows and the Tragedy of the Commons are both fine analogies. But the fields that originated them now have better ways of understanding the phenomena in question.

Last words

Maybe it’s time for the engineering community to re-examine Broken Windows as it pertains to technological asset quality and technical debt. At this time, the author is aware only of anecdotal support for the Broken Windows theory of technical debt management. Perhaps the Broken Windows theory will work better in engineering than it did in social science or criminology, but do you want to bet your company on that?

References

[APA 2013] American Psychiatric Association. Diagnostic and statistical manual of mental disorders (DSM-5®). Washington, DC: American Psychiatric Association Publishing, 2013.

The Order from Amazon

Cited in:

[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

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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Conroy 2012] Patrick Conroy. “Technical Debt: Where Are the Shareholders' Interests?,” IEEE Software, 29, 2012, p. 88.

Available: here; Retrieved: August 15, 2018.

Cited in:

[Cooper 1857] James Fenimore Cooper. The Last of the Mohicans, New York: Bantam Classics, 1982.

Order from Amazon

Cited in:

[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.

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:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Fowler 2006] Martin Fowler. “CodeSmell,” Martin Fowler (blog), February 9, 2006.

Available: here; Retrieved: June 6, 2018

Cited in:

[Fowler 2009] Martin Fowler. “Technical Debt Quadrant.” Martin Fowler (blog), October 14, 2009.

Available here; Retrieved January 10, 2016.

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Haque 2018] Md Shariful Haque, Jeff Carver, and Travis Atkison. "Causes, impacts, and detection approaches of code smell: a survey." Proceedings of the ACMSE 2018 Conference. ACM, 2018.

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291, 1998.

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kahneman 2011] Daniel Kahneman. Thinking, Fast and Slow. New York: Macmillan, 2011.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Li 2015] Zengyang Li, Paris Avgeriou, and Peng Liang. “A systematic mapping study on technical debt and its management,” Journal of Systems and Software 101, 193-220, 2015.

Cited in:

[Meadows 1997] Donella H. Meadows. “Places to Intervene in a System,” Whole Earth, Winter 1997.

Available: here; Retrieved: June 28, 2018

Cited in:

[Meadows 1999] Donella H. Meadows. “Leverage Points: Places to Intervene in a System,” Hartland VT: The Sustainability Institute, 1999.

Available: here; Retrieved: June 2, 2018.

Cited in:

[Meadows 2008] Donella H. Meadows and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing, 2008.

Order from Amazon

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017.

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] [

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] [

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

[Schein 2016] Edgar H. Schein. Organizational Culture and Leadership, Fifth Edition, San Francisco: Jossey-Bass, 2016.

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18, 57–62, 2005.

Available: here; Retrieved: April 5, 2018

Cited in:

[Thorndike 1920] Edward L. Thorndike. “A constant error in psychological ratings,” Journal of Applied Psychology, 4:1, 25-29, 1920. doi:10.1037/h0071663

The first report of the halo effect. Thorndike found unexpected correlations between the ratings of various attributes of soldiers given by their commanding officers. Although the halo effect was thus defined only for rating personal attributes, it has since been observed in assessing the attributes of other entities, such as brands. Available: here; Retrieved: December 29, 2017

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons