Tag: technical debt

Posted on

Controlling incremental technical debt

Last updated on July 16th, 2021 at 03:40 pm

A sinking rowboat provides a metaphor for controlling incremental technical debt
A sinking rowboat provides a useful metaphor for illustrating the process of controlling incremental technical debt. The enterprise is the rowboat. The leaks are the properties of the enterprise and its environment that lead to creating incremental technical debt. The water entering the boat through leaks is incremental technical debt. The accumulated water in the bottom of the boat is legacy technical debt.

All technical debt in enterprise assets is either incremental technical debt or legacy technical debt or both. Incremental technical debt is technical debt newly incurred. It can be newly incurred exogenous technical debt, or it can be endogenous technical debt incurred either in projects currently underway, or projects just recently completed. Legacy technical debt is technical debt associated with assets, and which wasn’t incurred recently or which exists in any form prior to undertaking work on those assets. All legacy technical debt was at some point incremental technical debt. The vast amounts of legacy technical debt most organizations now carry are nothing more than the accumulation of incremental technical debt. The path to managing legacy technical debt therefore begins with controlling incremental technical debt.

The leaky rowboat metaphor

Organizations are more likely to gain control of their legacy technical debt portfolio if they begin by controlling the formation of incremental technical debt, and its transformation into legacy technical debt. A metaphor might make this clear:

If you find yourself in a sinking rowboat, bailing out some of the water is a good idea. It might even be necessary in the short term. But at some point, fixing the leaks where the water comes in is advisable. Unless you address the existing leaks, and prevent new ones from forming, your fate is sealed. You’ll spend increasing portions of your time, energy, and resources bailing out your leaky rowboat. You’ll spend declining portions of your time, energy, and resources rowing the boat towards your objective. And when you do devote some time and energy to rowing towards your objective, you’ll find the rowing surprisingly difficult. The boat’s leaks make it ride lower in the water. And because you must propel not only the boat and its payload, but also the dead weight of the water in the bottom of the boat.

In this metaphor, legacy technical debt is the water in the bottom of the boat, and incremental technical debt is the water coming in through the leaks. The leaks are the proximate “causes” of technical debt. The root causes of the leaks are the root causes of technical debt.

Setting technical debt management priorities

If the enterprise is in the midst of a legacy technical debt emergency, retiring some of it is necessary in the short term. But unless the enterprise addresses incremental technical debt and its root causes, a new burden of legacy technical debt will accumulate. That accumulation is then likely to eliminate the benefits of having retired the current burden of legacy technical debt.

So after the legacy technical debt emergency is passed—or if resources permit, during the emergency—establishing measures, procedures, and practices for controlling incremental technical debt would be prudent.

This change might be less challenging than it sounds. With respect to endogenous incremental technical debt, the teams that incurred it are either still at work, or just recently dispersed. Their understanding of the incremental technical debt is still fresh in their minds. If their projects are still underway, and if budget and schedule permit, retiring the incremental technical debt in the context of those projects is a superior strategy. For projects that have already delivered their work, a less preferable but still practical approach involves re-assembling some of the team. They then work to retire the incremental technical deb, while memories are still fresh.

For incremental exogenous technical debt, the team that was active when the debt formed might have little knowledge of how the debt came to be. In those cases, re-assembling the team provides little advantage. Specialized knowledge of the technical debt might prove more helpful in devising a strategy for retiring it.

For the most part, the problem of controlling incremental technical debt isn’t a technical one. It usually reduces to a problem of finding time and resources to undertake the task.

Why resources aren’t available to retire incremental technical debt

The immediate reason why most teams don’t have enough resources to retire their incremental technical debt is that the organization, as a whole, doesn’t plan for retiring incremental technical debt incrementally. This immediate reason, though, isn’t fundamental. The lack of resources is a symptom of deeper dysfunctions in the organization. The real question is this: Why do so many organizations fail to allocate time and resources to retire incremental technical debt incrementally? Here are three reasons.

Misunderstanding (or no understanding) of the concept of technical debt

The organization is unlikely to be able to manage any kind of technical debt unless its people understand the concept. They must understand that technical debt isn’t necessarily the result of engineering malpractice. For example, much technical debt arises as a natural result of working with technology. Another example: it can be a result of organizational forms that compel people to behave in ways that lead to technical debt. Unless the people of the organization accept these truths, allocating sufficient resources to managing incremental technical debt is unlikely.

Not appreciating the MICs

Decisions regarding technical debt management ultimately reduce to a choice between allocating precious resources to technical debt retirement, and allocating them elsewhere. To make this choice responsibly, it’s necessary to fully appreciate the cost of carrying technical debt. Most believe that these costs appear in the form of lost engineering productivity. While that is indeed a factor, other factors can be far more important.

For example, if entry into an important market is delayed by even as little as 30 days due to debt-depressed engineering productivity, the financial consequences can be enormous and insurmountable. Or delays in diagnosing and repairing a fault in a product can produce financial liabilities that can actually sink the company. When one considers all possible financial consequences of carrying technical debt, it becomes clear that managing technical debt effectively is actually a strategy for survival. The decision to allocate appropriate resources to incremental technical debt retirement does require modeling these costs—calculations that few organizations actually undertake.

Miscalculating projections of returns on investments

Failing to estimate MICs with sufficient precision is problematic because it reduces the quality of decisions regarding short-term resource allocations. But it also affects long-term projections, which depend on estimating returns on investments. For example, to choose between investing in retiring incremental technical debt from an asset and investing in new capabilities for the same asset, one must compare the projected value of each choice. The investment decision could be biased in favor investing in new capabilities for many reasons. For example, the decision maker’s understanding of technical debt might be deficient. Another example: the calculations of MICs might be incomplete or underestimated. Incremental technical debt retirement might therefore be systematically deferred or avoided altogether.

The widespread belief that MICs consist largely of lost productivity of engineers almost ensures a dramatic underestimate of MICs.

Policy recommendations for controlling incremental technical debt

The simplistic approach to controlling incremental technical debt is to provide more money to projects and to engineering functions. While that approach will be somewhat helpful, its results will likely be disappointing when compared to approaches that combine resource augmentation with changes in enterprise policy, processes, and culture.

Let’s begin with an example of a needed cultural change. Nearly anyone who makes or influences decisions might occasionally bear some responsibility for incurring incremental technical debt. To achieve effective control of technical debt requires that everyone understand how to change their behavior. Any guiding principle must be simple to state and easy to understand, because we must communicate it to nearly everyone. Here’s a sample statement of a useful such a principle:

Those whose decisions lead to new technical debt are accountable for securing the resources needed to retire that debt. They might also be accountable for supplying compensating resources to those within the enterprise, or among its customers, who are negatively affected. For example, those negatively affected might suffer depressed operational effectiveness during the period in which that technical debt is outstanding.

I call this the Principle of Accountability. It’s a corollary to what Weinberg calls “Ford’s Fundamental Feedback Formula” [Weinberg 1985], which captures the idea that people make better choices when they must live with the consequences of those choices.

General guiding principles are necessary, but not sufficient. Here are five examples of changes that help in controlling incremental technical debt [Brenner 2017b].

1.       Adopt a shared concept vocabulary

There must be general agreement among all parties about the meanings of concepts that relate to incremental technical debt formation.

Examples: the definitions of “done” vis-à-vis projects, strategic technical debt, reckless technical debt, unethical technical debt, exogenous-technical-debt, endogenous technical debt, MICs, MPrin, and more. This material must be available in an education program and a new-employee orientation program.

2.       Accept that technical debt is a fact of technological life

There is a widespread belief that most technical debt results from engineering malpractice. Although some technical debt does arise this way, most does not. For examples of other causes, see “Nontechnical precursors of nonstrategic technical debt.” Some technical debt arises because of advances external to the enterprise, beyond its control. Development-induced or field-revealed discoveries are especially difficult to avoid. In many instances, technical debt is an inevitable result of using technology.

3.       Track the cost of carrying technical debt

The cost of retiring a particular class of technical debt (its MPrin) is significant only in the context of planning or setting priorities for resource allocation. In all other contexts, knowing that cost has little management value. What does matter, at all times, is the cost of carrying that technical debt—the MICs, or metaphorical interest charges. (See “The Principal Principle: Focus on MICs.”) MICs can fluctuate wildly [Garnett 2013].

Build and maintain expertise for estimating and tracking the costs of incurring and carrying each class of technical debt. Know how much each kind of technical debt contributes to these costs, now and for the next few years.

4.       Assign accountability for kinds of technical debt

Some kinds of incremental technical debt result from actions (or inactions) within the enterprise. Some do not. To control the incremental technical debt that arises from internal causes, hold people accountable for the debt their actions generate. Use Fowler’s Technical Debt Quadrant [Fowler 2009] as the basis for assessing and distributing internal financial accountability. It’s useful for both debt retirement costs (MPrin) and metaphorical interest charges (secured technical debt is technical debt for which resources have been allocated (possibly in a forward time period) to guarantee the debt’s retirement and possibly its associated MICs.

This policy implies that deliberately incurred technical debt, whether incurred strategically or recklessly, must be secured. If anyone involved feels that technical debt has been incurred, a dispassionate third party reviews project deliverables for the presence of technical debt. However, allocating resources might require securing commitments of resources for future fiscal periods. For many organizations, such forward commitments might require modifying the management accounting system.

Last words

Controlling incremental technical debt requires changes well beyond the behavior and attitudes of engineering staff, or the technologies they employ. Achieving control of incremental technical debt formation requires engagement with enterprise culture to alter the behavior and attitudes of most of the people of enterprise.

References

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

Retiring technical debt from irreplaceable assets

Last updated on July 14th, 2021 at 07:38 pm

A map of the U.S. Interstate Highway System, which many regard as one of our irreplaceable assets
A map of the U.S. Interstate Highway System. The map shows primary roadways, omitting most of the urban loop and spur roads that are actually part of the system. In 2016, the total length of highways in the system was about 50,000 miles (about 80,000 km). About 25% of all vehicle miles the U.S. occur in this system. The cost to build it was about USD 500 billion in 2016 currency. Significant advances have occurred since the 1950s in technologies such as rail, electronics, data management, and artificial intelligence. And the effects of fossil fuel combustion on global climate are well known. One wonders whether such a system would be the right choice if construction were to begin today. If alternatives would be better, then this system might be regarded as technical debt. But replacing it might not be practical. Finding a way to retire the technical debt without replacing the entire asset might be the most viable solution. Image by SPUI courtesy Wikipedia.

Designing a project to retire some portion of the technical debt from a critical, irreplaceable asset, can be a daunting task. It’s best to acknowledge that the project design problem is very likely a wicked problem in the sense of Rittel and Webber [Rittel 1973]. See my post “Retiring technical debt can be a wicked problem” for more. In this thread, of which this is the first post, I suggest some basic preparations for dealing with irreplaceable assets. They form a necessary foundation for success in approaching the debt retirement problem for irreplaceable assets.

Wicked problems

As I’ve noted in previous posts, the problems associated with retiring technical debt can be wicked problems. And if some of these problems aren’t strictly wicked problems, they can possess many of the attributes of wicked problems in degrees sufficient to challenge the best of us. That’s why approaching a technical debt retirement project as you would any other project is risky.

For convenience and to avoid confusion, in my last post I adopted the following terminology:

  • DRP is the Debt Retirement Project
  • DDRP is the effort to design the DRP
  • DBA is the set of Debt Bearing Assets undergoing modification in the context of the DRP
  • IA is the set of assets, excluding the DBA assets, that interact directly or indirectly with assets in the DBA

In the posts in this thread, convenience demands that we add at least one more shorthand term:

  • TDIQ is the Technical Debt In Question. That is, it’s the kind of technical debt we’re trying to retire from the DBA assets. Other instances of the TDIQ might also be found elsewhere, in other assets, but retiring those instances of the TDIQ is beyond the scope of the DRP.

Know when and why we must retire technical debt

For those technical debt retirement projects (DRPs) that exhibit a high degree of wickedness, a critical success factor is clear communication of the mission of the DRP. Clear communication is important because the DRP team must deal with many stakeholders who are in the early stages of familiarity with the concept of technical debt. Some of them might be cooperating reluctantly. Expressing the objectives and benefits of the DRP in a clear and inspiring way is very helpful. With that in mind, I offer the following reminder of the reasons for tackling such a large and risky project that produces so few results immediately visible to customers.

Examining alternatives to retiring the TDIQ is a good place to begin. One alternative is simply letting the TDIQ remain in place. Call this alternative “Do Nothing.” A second alternative to retiring the TDIQ is replacing the debt-bearing asset with something fresh and clean and debt-free. Call this alternative “Replace the Asset.” The problem many organizations face is that they cannot always rely on these alternatives. And because these two alternatives to debt retirement aren’t always practical, some organizations must develop the expertise and assets necessary to retire widespread technical debt in large, critical, irreplaceable systems. Below is a high-level discussion of these two alternatives to debt retirement.

Do Nothing

The first alternative is to find ways to accept that the DBA will continue to operate in their current condition, carrying the technical debt that they now bear. This alternative might be acceptable for some assets, including those that are relatively static and which need no further enhancement or extension. This category also includes those assets the organization can afford to live without.

One disadvantage of the “Do Nothing” approach is that technology moves rapidly. What seems acceptable today might not be acceptable in the very near future. It might become old-fashioned, behind the times, or non-compliant with future laws or regulations. Styles, fashions, technologies, laws, regulations, markets, and customer expectations all change rapidly. And even if the asset doesn’t change what it does, the organization might need to enhance the asset. The enhancements might become very expensive to accomplish due to the technical debt the asset carries.

An especially troubling scenario takes shape when the DBA contains portions that are severely out of date. When that happens the organization might no longer be able to find qualified candidates who can perform needed work on the DBA. This situation can also arise when portions of the DBA were developed in-house. In that case, there might not be any qualified candidates outside the organization. When everyone who understands the DBA has departed the organization, work can proceed only if the DBA is properly documented and a training and mentoring program is healthy and current.

For these reasons, Do Nothing can be a high-risk strategy.

Replace the Asset

The second alternative to retiring the TDIQ is to replace the entire asset. For this option, the question of affordability arises. In some instances this alternative is practical, but for many assets, the organization simply cannot afford to purchase or design and construct replacements.

Pay special attention to those assets that “learn.” They might contain data gathered from experience over a long period of time. Retiring the asset can require developing some means of recovering the experience data and migrating it to the replacement asset. That task is a potentially daunting effort in itself.

Replacement is especially problematic when the asset is proprietary. If the organization created the asset itself, they might have constructed it over an extended period of time. Replacement with commercial products could require extensive adaptation of those products, or adaptation of organizational processes. Worse yet, replacement with assets of its own making will likely be costly.

Last words

When organizations depend on assets that they must enhance or extend, and which they cannot afford to replace, they face a daunting problem. They must develop the expertise and resources needed to address the technical debt that such assets inevitably accumulate.

This series of posts explores the issues that arise when an organization undertakes to retire the technical debt that its irreplaceable assets are carrying. Below, I’ll be inserting links to the subsequent posts in this series.

Other posts in this thread

References

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:
Posted on

Managing technical debt

Last updated on July 11th, 2021 at 02:56 am

A jumble of jigsaw puzzle pieces. Managing technical debt can be like solving a puzzle.
A jumble of jigsaw puzzle pieces. Managing technical debt can be like solving a puzzle. Where do we begin? With jigsaw puzzles, we usually begin with two assumptions. First, we assume that we have all the pieces. Second, we assume that they fit together to make a coherent whole. These assumptions might not be valid for the puzzle of technical debt in any given organization.

Managing technical debt is something few organizations now do. And fewer do well. Several issues make managing technical debt difficult and they’re discussed elsewhere in this blog. This thread explores tactics for dealing with those issues from a variety of initial conditions. For example, tactics that work well for an organization that already has control of its technical debt, and which wants to keep it under control, might not work at all for an organization that’s just beginning to address a vast portfolio of runaway technical debt. The needs of these two organizations differ. The approaches they must take might then also differ.

What’s in this thread

The first three posts in this thread illustrate the differences among organizations in different stages of developing technical debt management practices. In “Leverage points for technical debt management,” I begin to address the needs of strategists working in an organization just beginning to manage its technical debt. They ask the question, “Where do we begin?” In “Undercounting nonexistent debt items,” I offer an observation about a risk that accompanies most attempts to assess the volume of technical debt. Such assessments are frequently undertaken in organizations at early stages of the technical debt management effort. In “Crowdsourcing debt identification,” I discuss a method for maintaining the contents of a database of technical debt items. Data maintenance is something we might undertake in the context of a more advanced technical debt management program.

Obstacles we must address

Whatever approach is adopted, it must address factors that include technology, business objectives, politics, culture, psychology, and organizational behavior. So what you’ll find in this thread are insights, observations, and recommendations that address one or more of the issues related to these fields. “Demodularization can help control technical debt” considers mostly technical strategies. “Undercounting nonexistent debt items” is an exploration of a psychological phenomenon.  “Leverage points for technical debt management” considers the organization as a system and discusses tactics for altering it. And “Legacy debt incurred intentionally” explores how existing technical debt can grow as long as it remains outstanding.

Accounting issues also play a role. For example, “Metrics for technical debt management: the basics” is a basic discussion of measurement issues. A second example: “Accounting for technical debt” looks into the matter of accounting for technical debt financially. And “Three cognitive biases” is a study of how the way we think about technical debt affects the technical debt portfolio.

Posts in this thread:

References

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:
Posted on

Crowdsourcing debt identification

Last updated on July 10th, 2021 at 03:29 pm

I’ve often expressed the view that the people of the organization know where much of their technical debt is. Or they can find it quickly. To exploit this resource, what’s needed is a systematic method for gathering what they know. If we do, we can produce a database that can serve as a starting point for further investigation. We might call this part of the debt identification process “crowdsourcing debt identification.”

Crowdsourcing debt identification is gathering what employees know
A crowd. Crowds are powerful when they coordinate their actions.

When an organization first undertakes to manage its technical debt, one of the many initial tasks is identifying its existing technical debt. There are tools for executing some of this task, at least for software assets, and they are useful. But because they’re in an early stage of development, and because many non-software assets also carry technical debt, human assistance is required. And that’s the place where crowdsourcing can help.

An example of crowdsourcing debt identification

For example, if you ask engineers for examples of technical debt in the assets they work on regularly, they can rattle off a few examples without hesitation. But a few days later, while working on whatever task has focus that day, they’ll realize that they could have mentioned another painful item. And they’ll want to report it. Gathering that kind of information is very helpful to the debt identification effort. That’s crowdsourcing in action.

But investment is required for crowdsourcing to be effective. We must educate the people who will be doing the reporting, and we must give them tools to make reporting quick and easy.

Reporting issues

Crowdsourcing debt identification will produce a stream of “incident reports” by Debt Reporters (DRs). People we might call Debt Report Administrators (DRAs) could then interpret the reports. Then they could recast the reports for later investigation by experts in the assets involved. Common difficulties that add to workload of DRAs include the items below.

Inconsistent definitions of technical debt

Lack of uniformity in understanding what technical debt is and isn’t can cause DRs to report as potential debt items some artifacts that aren’t manifestations of technical debt. Worse, they might fail to report items that are technical debt.

Only educating the DRs about the organizational definition of technical debt can enhance consistency.

Repeated reporting of previously reported debt items

Unaware that a previous report has identified a debt item, DRs might file reports unnecessarily. Some of these duplications are obvious. But if the language of the report is different enough, identifying duplicates can take time.

< p class="left-indent">We can reduce duplication by making available descriptions of previously reported items in multiple forms.

Inconsistent descriptions of debt items

DRA must be able to recognize when two different DRs use different language to describe the same debt item. If they do not, then the debt report database will contain an unrecognized duplication.

The asset expert must then address this situation.

Failure to report known debt items

Some people, pressed by the urgency of their “own work,” might not report debt items they know about, or might hurriedly file low-quality reports. A high incidence of this behavior is an indicator of a deeper organizational issue: namely, that some people do not regard technical debt management as a worthy activity.

Tracking report quality and report frequency is one way to determine how much regard the people of the organization have for the debt management effort.

Report format and content

Reporting a potential technical debt item must not be burdensome. It must be easy. A Web-based form is a minimum. Users must be able to prefill some fields common to all their reports, and save the result as a template. Fields they might want to prefill include their personal identity and the asset identity. DRs might need several templates, depending upon the number of assets with which they interact. Switching from one template to another must also be easy.

Several authors have proposed report templates, Below is one due to Foganholi, et al. [Foganholi 2015]. (TD is technical debt)

IDTD identification number
DateDate of TD identification
ResponsiblePerson or role who should fix this TD item
TypeDesign, documentation, defect, testing, or other type of debt
ProjectName of project or software application
LocationList of files/classes/methods or documents/pages involved
DescriptionDescribes the anomaly and possible impacts on future maintenance
Estimated principalHow much work is required to pay off this TD item on a three-point scale: High/Medium/Low
Estimated interest amountHow much extra work will need to be performed in the future if this TD item is not paid off now on a three-point scale: High/Medium/Low
Estimated interest probabilityHow likely is it that this item, if not paid off, will cause extra work to be necessary in the future on a three-point scale: High/Medium/Low
IntentionalYes/No/Don’t Know
Fixed byPerson or role who really fix this TD item
Fixed dateDate of TD conclusion
Realized principalHow much work was required to pay off this TD item on a three-point scale: High/Medium/Low
Realized interest amountHow much extra work was needed to be performed if this TD item was not paid off at moment of detection, on a three-point scale: High/Medium/Low

While this template might be useful for tracking the technical debt item, it contains fields that aren’t needed for crowdsourcing debt identification. A simplified template for crowdsourcing debt identification might look like this:

Identifying Report TitleYour identifier for this report
DateDate of report (prefilled)
TypeDrop down menu of debt types, including “other”
ProjectName of the project sponsoring the work which led to your observation of the debt item
Location of debt itemList of assets involved, including specific location within complex assets
DescriptionDescribe the debt item including
  • Whether your current effort has created it and if so, how

  • Possible impact on present or future maintenance or enhancement efforts

  • Whether it has led to, or is a result of, contagion

  • How it’s affecting your work
IntentionalYes/No/Don’t Know

Asset experts then receive these reports and take one or more of the following actions:

  • Seek further information from the DR.
  • Reject the report as not involving technical debt. Rejection data is part of the basis for assessing the effectiveness of the education program.
  • Attach the report to a new or existing debt item, incorporating relevant information from the report into the debt item’s data.

The asset experts produce contains information like that suggested by Foganholi, et al.. It can be the basis of further analysis and eventual retirement of the debt item.

Last words

Investment in ease-of-use for the reporting process is essential for at least three reasons:
  • Some might regard reporting as an additional burden beyond the current workload.
  • In many organizations, some might regard reporting as a secondary responsibility.
  • Unless technical debt retirements rapidly become common occurrences, some might regard reporting as a waste of effort. The reporting itself must therefore be easy.

These phenomena all exert negative pressure on report quality. They tend to suppress report frequency. Ease-of-use can mitigate these effects.

References

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Related posts

  • Nine indicators of wickedness
    By carefully observing what happens when we actually try to retire some kinds of technical debt, we can better understand the degree of the degree of wickedness of the effort. That understanding helps manage risk in technical debt retirement projects, reducing costs and speeding execution.
  • Degrees of wickedness
    Designing technical debt retirement projects can be a wicked problem. But there can be degrees of wickedness. And wickedness can have dimensions, too.
  • Retiring technical debt can be a super wicked problem
    A subset of wicked problems can be viewed as super wicked, if time is running out, if the central authority fails to act, and if the people who cause them influence the solution. Some technical debt retirement situations qualify as super wicked problems.
  • Retiring technical debt can be a wicked problem
    Retiring technical debt isn’t just a problem, it’s a wicked problem. And that explains many of the difficulties we associate with retiring technical debts that involve many stakeholders, assets, revenue streams, infrastructure, architectures, policies, or strategies.
  • Synergy between the reification error and confirmation bias
    The tendency to underestimate technical debt retirement costs is due, in part to the interaction between the consequences of the reification error and the consequences of confirmation bias. Here are some recommendations for mitigating these effects.
  • Managing technical debt
    Managing technical debt is something few organizations now do, and fewer do well. This thread explores tactics for dealing with a variety of technical debt situations.
Posted on

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

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

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

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

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

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

The Tragedy of the Commons is a distraction

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

A map of the Boston Common and Public Garden, circa 1890. This is the kind of “common” referred to in the tragedy of the commons.
A map of the Boston Common and Public Garden, circa 1890. By 1890 it was basically a park. But as late as 1830 it was still in use as a cow pasture. Home refrigeration was rare then, except by ice blocks. The best way to get fresh dairy products was to have a cow. In the very early days, 1633-1640, anyone could graze on the Common. But as wealthy people acquired more animals, the common became overgrazed. A 70-cow limit was imposed. That limit stood until 1830. It’s an example of a method for managing a shared resource. This map is from an atlas of Boston published by G.W. Bromley & Co., courtesy Wikimedia Commons

Many believe that technical debt arises, in part, because of a phenomenon known as the Tragedy of the Commons [Hardin 1968]. The Tragedy of the Commons is an allegory that purports to demonstrate how shared resources degrade. It holds that the user communities associated with shared resources inevitably degrade those resources until they’re depleted. The allegory supposedly supports the thesis that only monocratic control of an asset can provide the strict regulation that prevents its inevitable degradation. Advocates of this approach to limiting the degradation arising from the expansion of technical debt hold that assigning sole ownership of resources, resource by resource, is the only effective method of controlling technical debt.

How adherents of the theory manage shared assets

The resources in question here are the assets that tend to accumulate technical debt. Adherents of the theory would impose order by dividing each technological asset into one or more sectors, sometimes called development silos. Each development silo would have one organizational unit designated as the “owner.” Owners have the power to develop, maintain, or extend that sector [Bossavit 2013] [Morris 2012]. They would presumably resolve irreconcilable disagreements about the direction or purpose of a particular sector by branching.

Ironically, such an approach would—and demonstrably does—produce significant technical debt in the form of duplication of artifacts and services. Moreover, it elevates costs relative to a truly shared asset. Costs increase because of reduced sharing and increased need for testing. We can regard such an approach as dysfunctional conflict avoidance [Brenner 2016b].

How adherents apply the theory to explain technical debt

At one time researchers in political economics regarded the Tragedy of the Commons as universally valid. But subsequent research has demonstrated that the principle it describes isn’t generally applicable. Hardin first described the Tragedy of the Commons in 1968, in the form of an allegory [Hardin 1968]. In his words:

Picture a pasture open to all. It is to be expected that each herdsman will try to keep as many cattle as possible on the commons. Such an arrangement may work reasonably satisfactorily for centuries because tribal wars, poaching, and disease keep the numbers of both man and beast well below the carrying capacity of the land. Finally, however, comes the day of reckoning, that is, the day when the long-desired goal of social stability becomes a reality. At this point, the inherent logic of the commons remorselessly generates tragedy.

As a rational being, each herdsman seeks to maximize his gain. Explicitly or implicitly, more or less consciously, he asks, “What is the utility to me of adding one more animal to my herd?”

Hardin then explains that the logic of the situation compels each herdsman to exploit the shared resource to the maximum. Each herdsman puts his or her own interests ahead of the welfare of the resource.

But the theory doesn’t work

And so it goes, supposedly, with technical debt. Each user of the shared asset expends resources on development, maintenance, and enhancement only to the extent that the immediate need justifies the expenditure. Retiring any legacy technical debt, or any technical debt accumulated in the course of meeting those immediate needs, is regarded as low priority. Because resources for debt retirement are rarely if ever sufficient to meet the need, technical debt grows inexorably. Eventually, the organization abandons the shared asset because it becomes unmaintainable.

However, careful research shows that Hardin’s Commons allegory isn’t applicable to every situation involving shared resources. That same research casts doubt on the validity of the assertion that development silos are necessary in any approach to technical debt management.

Enter Elinor Ostrom

Certainly there are many examples of shared resources degrading along the lines Hardin suggests. An example is the collapse of the Northwest Atlantic cod fishery [Frank 2005]. But many counterexamples exist. Research by the late political economist Elinor Ostrom uncovered numerous examples of complex social schemes for maintaining common resources sustainably [Ostrom 2009] [Ostrom 1990]. Ostrom reported on systems that successfully managed shared resources over long terms—in some cases, centuries. For this work, she received the Nobel Prize in Economics in 2009.

As Ostrom’s research demonstrated, the problem with Hardin’s allegory is that it applies only to resources open to unregulated use. A World Bank Discussion Paper by Bromley and Cernea [Bromley 1989] clearly describes the misapplication of the Tragedy of the Commons:

For some time now, Hardin’s allegory of the “tragedy” has had remarkable currency among researchers and development practitioners. Not only has it become the dominant paradigm within which social scientists assess natural resource issues, but it appears explicitly and implicitly in the formulation of many programs and projects and in other beliefs and prejudices derived from it. Unfortunately, its capacity for aiding our understanding of resource management regimes falls far short of its power as a metaphor. By confusing an open access regime (a free-for-all) with a common property regime (in which group size and behavioral rules are specified) the metaphor denies the very possibility for resource users to act together and institute checks and balances, rules and sanctions, for their own interaction within a given environment.

Hardin himself later published an extension of the allegory that clarified the role of regulation [Hardin 1998]. Lloyd had observed this much earlier [Lloyd 1833].

The real tragedy of the Tragedy of the Commons

The real tragedy for technology managers would be their failure to learn from the past errors of social scientists and political economists. If they then repeat this now well-understood confusion about the domain of applicability of Hardin’s allegory, they would be compounding the tragedy.

We can apply Ostrom’s result to the problem of managing technical debt if we identify the technical asset as the shared resource. Next we would identify as the community exploiting the resource the stakeholders who employ, develop, maintain, cyber-defend, or extend that technical asset. Ostrom’s results tell us that sustainable exploitation is possible. If the community devises rules, customs, and sanctions that manage the technical debt, the resource is sustainable. Kim and Wood [Kim 2011] provide an analysis that explains how regulation can avert depletion scenarios. Technology managers can apply these lessons to the problem of managing technical debt.

Last words

The Tragedy of the Commons is a distraction. Technical debt isn’t an inevitable result of sharing assets when the organization adheres to a Principle of Sustainability. That principle is that sustainability is possible if the community sharing the asset devises customs, rules, and sanctions that control technical debt. You just can’t have a free-for-all unregulated regime, as most organizations now do. Management and practitioners must collaborate to manage the asset. And regular updating of the customs, rules, and sanctions is probably necessary. Leadership in devising those customs, rules, and sanctions is a job for the policymaker.

References

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

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

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:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

Organizational psychopathy: career advancement by surfing the debt tsunami

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

The aftermath of the 2004 Indian Ocean earthquake, 26 December 2004
The aftermath of the 2004 Indian Ocean earthquake and tsunami, 26 December 2004. Shown is what remained of Meulaboh, Sumatra, Indonesia, after the tsunami struck. The photo was taken on January 10. At the lower left is a Landing Craft Air Cushion (LCAC) hovercraft vehicle, assigned to USS Bonhomme Richard (LHD-6), delivering supplies. LCACs are capable of transporting more supplies than helicopters in a single trip. The technical debt devastation left behind after an organizational psychopath moves on to further conquests can be just as overwhelming as the physical devastation left behind after a tsunami. Photo by U.S. Navy courtesy Wikimedia Commons.

During policy debates, some advocates take positions that offer short-term advantages in exchange for long-term disadvantages. The long-term disadvantages are often in the form of new technical debt. Or they might advocate allowing legacy technical debt to remain in place. Some of these decisions can be strategic, and they can benefit the enterprise. But when the primary beneficiary of the strategy is the decision maker or the advocate, a dominant contributing factor can be organizational psychopathy. This risk is higher when he or she intends knowingly to move on to a new position or to employment elsewhere before the true cost of the technical debt becomes evident.

Such decisions can be counterproductive for the enterprise in the long term. But decision makers or advocates nevertheless favor these decisions, because they plan to take credit for the short-term benefits. They then move on to new career positions elsewhere to escape the technical debt problems they created. In effect, the decision maker or advocate plans to “surf the debt tsunami.”

The organizational psychopath

People who adopt strategies of this kind might be following the pattern of organizational psychopathy [Babiak 2007] [Morse 2004]. Organizational psychopaths compulsively seek power and control over others. They use a vast array of tactics, but the tactic of greatest relevance to this discussion is the use of enterprise resources to advance the psychopath’s career. Technical debt provides a mechanism for borrowing future resources to enhance present performance, thus advancing the career of the psychopath. It’s especially attractive to the psychopath because the harmful consequences of technical debt can remain hidden until the psychopath has long ago moved on.

Psychopaths are better equipped than most to execute such strategies. They can be exceedingly charming, intelligent, charismatic, and adept at deception. They’re willing to conceal the truth about the technical debt they create, misrepresenting its costs and consequences, or concealing it altogether. Most important, organizational psychopaths seem to lack the internal regulators of conscience and compunction that limit the actions of non-psychopaths. For example, in a debate about a specific technical decision, the psychopath is willing to use any tools available to win the point, including using deception to destroy the career of anyone who challenges the psychopath’s position.

Last words

Babiak and Hare estimate that the incidence of psychopathy in senior positions in business is about 3-4%—between 1/30 and 1/25. However, I’m unaware of any studies of the strategic use of technical debt by these individuals. It’s reasonable to suppose that technical debt has been so employed, but the significance of this phenomenon is unknown. Serious investigation is in order.

References

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

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

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:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

Unrealistic definition of done

Last updated on July 8th, 2021 at 01:20 pm

Many an enterprise culture includes, perhaps tacitly, an unrealistic definition of done for projects. Some enterprise cultures assume definitions of done that fail to adequately acknowledge attributes related to sustainability. For such cultures, technical debt expands inexorably. In most organizations, the definition of done includes meeting the attributes that most internal customers understand and care about. These attributes might not include sustainability [Guo 2011]. Indeed, even among technologists, the definition of done might not enjoy precise consensus [Wake 2002].

Why retiring technical debt isn’t included in “done”

The 2009 Ford Focus SES coupe (North America) engine bay. Its design is “done” in the sense that it’s available to consumers.
The 2009 Ford Focus SES coupe (North America) engine bay. Typical owners can no longer learn how to maintain their own vehicles. Engines have become so complex that even experienced mechanics must train to maintain the engines they work on. Since these vehicles are available for sale to consumers, clearly their manufacturers regard their designs as “done.” But is technical debt a factor in the growing complexity of modern engines? It’s probably present in their software, and it would be most surprising if we found no technical debt in the mechanical design. Photo (cc) Porsche997SBS courtesy Wikimedia.
Internal customers understand less well the attributes of deliverables related to sustainability. It’s therefore perhaps unsurprising that sustainability might not receive the attention it needs. Applying scarce resources to enhance attributes the customer doesn’t understand, and cares about less, will always be difficult.

To gain control of technical debt, we must redefine done to include addressing sustainability of deliverables. Although there may be many ways to accomplish this, none will be easy. Resolution will necessarily involve educating internal customers to understand enough about sustainability to enable them to justify paying for it.

Redefining “done”

The typical definition of done for most projects ensures only that the deliverables meet the requirements. Because requirements usually omit reference to retiring newly incurred nonstrategic technical debt, we often declare projects complete with incremental technical debt still in place. A similar problem prevails with respect to legacy technical debt.

A more insidious form of this problem is intentional shifting of the definition of done. This can happen when the organization has adopted a reasonable definition of done that allows for addressing sustainability. But under severe time pressure, the definition is “temporarily” amended to allow the team to declare the effort complete, even though sustainability issues remain unaddressed.

For most projects, three conditions conspire to create steadily increasing levels of nonstrategic technical debt. First, for most tasks, the definition of done is that the deliverables meet the project objectives, or at least, they meet them well enough. Second, typical project objectives don’t restrict levels of newly incurred nonstrategic technical debt, nor do they demand retirement of incidentally discovered legacy technical debt. Third, budget authority usually terminates upon acceptance of delivery. These three conditions, taken together, restrain engineering teams from immediately retiring any debt they incur. Nor can they retire—or document or report—any legacy technical debt they encounter while fulfilling other requirements.

For example, for one kind of incremental technical debt—what Fowler calls [Fowler 2009] Inadvertent/Prudent (“Now we know how we should have done it”)—the realization that we’ve incurred new debt often occurs after the task is “done.” If budget authority has terminated, there are no resources available—financial or human—to retire that form of technical debt.

Last words

Unless team members document the technical debt they create or encounter, there is risk of lost knowledge. After team members move on to their next assignments the enterprise is likely to lose track of the location and nature of that debt. A more realistic definition of done would enable the team to continue working post-delivery to retire or document any newly incurred nonstrategic technical debt. They could also note any incidentally encountered legacy technical debt. Moreover, teams most likely leave in place any strategic technical debt—technical debt incurred intentionally for strategic reasons. Although the enterprise must eventually address such debt as well, the widespread definition of done doesn’t address it.

Policymakers are well positioned to advocate for the culture transformation needed to redefine done.

References

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

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

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:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Posted on

Team composition volatility

Last updated on July 7th, 2021 at 07:51 pm

Now we know what we should have done.
“Now we know what we should have done.” This is one kind of incremental technical debt. When the composition of a development team changes over the course of a project, recognizing how the team should have been done things can become more difficult.

Team composition volatility can interfere with technical debt retirement. In many organizations, project team composition evolves from the beginning of the project to its end. In most teams, people who have special knowledge cycle in and out as the work requires. These changes in team composition might not interfere with completing a team’s primary objectives.

But these changes can affect the team’s ability to retire technical debt incurred over the life of the project. Changes in team composition can also limit the team’s ability to retire specified legacy technical debt that it encounters while working toward its primary objectives.

The likelihood of incurring nonstrategic incremental technical debt can also increase when team composition changes. Changes can also reduce the likelihood of retiring all legacy debt specified in the team’s objectives.

Why team composition volatility matters for incremental technical debt

Groups we call teams are responsible for carrying out most product development, maintenance, and enhancement. In this context, team usually refers to, “a small group of interdependent individuals who share responsibility for outcomes.” [Hollenbeck 2012] However, as Hollenbeck, et al., observe, teams vary widely in both skill differentiation and composition stability. My sense is that both factors can potentially influence a team’s ability to retire incremental technical debt. They also affect its ability to achieve its objectives with respect to retiring legacy technical debt.

For example, consider what Fowler calls the Inadvertent/Prudent class of technical debt—“Now we know how we should have done it.” [Fowler 2009] In a project of significant size, some might recognize that different approaches to all or parts of the project would have been better choices. The recognition might come several months or years after completion of the work.

But for the moment, consider only cases in which the recognition occurs during the project, or shortly after completion. In these cases, the people who performed that work might have moved on to other teams. The people who now realize “how we should have done it” might themselves be incapable of making the needed changes, even if they have the budget or time to do the work. Or worse, they might not have the knowledge needed to recognize that a different approach would have been more effective. In either case, recognized or not, the work in question comprises incremental technical debt. Because of team composition volatility, recognizing or retiring that incremental technical debt can be difficult.

Why team composition volatility matters for retiring legacy technical debt

Team composition volatility can also interfere with retiring legacy technical debt. Some projects have specific goals of retiring a class or classes of legacy technical debt. But others with different objectives might also be charged with retiring instances of legacy technical debt as they encounter them. When we reassign team members who have special knowledge required for the team’s primary objectives, some legacy technical debt can remain extant, if retiring that debt requires their special knowledge. It can also remain extant if the reassignment occurs before they can complete the legacy debt retirement. This mechanism is more likely to occur when the legacy debt retirement objective seems subordinate to other business objectives.

Last words

Keeping team membership stable has big advantages relative the technical debt management. Said differently, organizations that must shuffle people from team to team as a consequence of controlling costs by reducing headcount can pay big penalties in terms of increasing loads of technical debt.

References

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

This article is probably the source of the adage “You are what you measure.” Personally, I believe it’s overstated. That is, it’s true in the large, perhaps, but not in detail. Moreover, there are some things that we are that can’t be measured. But it’s important to understand the content of this article because so many people take it as dogma. Available: here; Retrieved: June 4, 2018

Cited in:

[Babiak 2007] Paul Babiak and Robert D. Hare. Snakes in Suits: When Psychopaths Go to Work. New York: HarperCollins, 2007. ISBN:978-0-06-114789-0

An accessible and authoritative overview of organizational psychopathy. Order from Amazon

Cited in:

[Bossavit 2013] Laurent Bossavit (@Morendil), “Zero Code Ownership will lead to a tragedy-of-the-commons situation, where everybody bemoans how ‘technical debt’ makes their job suck.”, a tweet published April 20, 2013.

Available: here; Retrieved December 29, 2016.

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:

[Brenner 2016b] Richard Brenner. “Some Causes of Scope Creep,” Point Lookout 2:36, September 4, 2002.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2017b] Richard Brenner. “Managing Technical Debt: Nine Policy Recommendations,” Cutter Consortium Executive Update 18:4, 2017.

Available: here; Retrieved: December 29, 2017

Cited in:

[Bromley 1989] Daniel W. Bromley and Michael M. Cernea. “The Management of Common Property Natural Resources: Some Conceptual and Operational Fallacies.” World Bank Discussion Paper WDP-57. 1989.

Available here; Retrieved December 29, 2016.

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:

[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015, 4.

Available: here; Retrieved: July 7, 2018

Cited in:

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

Available here; Retrieved January 10, 2016.

Cited in:

[Frank 2005] Frank, Kenneth T., Brian Petrie, Jae S. Choi, William C. Leggett. "Trophic Cascades in a Formerly Cod-Dominated Ecosystem." Science. 308 (5728): 1621–1623. June 10, 2005.

Available here; Retrieved: March 10, 2017.

Cited in:

[Garnett 2013] Steve Garnett, “Technical Debt: Strategies & Tactics for Avoiding & Removing it,” RippleRock Blog, March 5, 2013.

Available: here; Retrieved February 12, 2017.

Cited in:

[Guo 2011] Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, and Clauirton Siebra. “Tracking Technical Debt: An Exploratory Case Study,” 27th IEEE International Conference on Software Maintenance (ICSM), 2011, 528-531.

Cited in:

[Hardin 1968] Garrett Hardin. “The Tragedy of the Commons,” Science, 162, 1243-1248 1968.

Available: here; Retrieved December 29, 2016.

Cited in:

[Hardin 1998] Garrett Hardin. “Extensions of ‘The Tragedy of the Commons’,” Science, May 1, 1998: Vol. 280, Issue 5364, 682-683.

Available: here; Retrieved: July 30, 2017

Cited in:

[Hollenbeck 2012] John R. Hollenbeck, Bianca Beersma, and Maartje E. Schouten. “Beyond Team Types and Taxonomies: A Dimensional Scaling Conceptualization for Team Description,” Academy of Management Review, 37:1, 82–106, 2012. doi:10.5465/amr.2010.0181

Available: here; Retrieved: July 8, 2017

Cited in:

[Kim 2011] Daniel H. Kim and Virginia Anderson. Systems Archetype Basics: From Story to Structure, Waltham, Massachusetts: Pegasus Communications, Inc., 2011

Available: here; Retrieved: July 4, 2017 Order from Amazon

Cited in:

[Lloyd 1833] Lloyd, W. F. Two Lectures on the Checks to Population, 1833.

Available: here; Retrieved: July 30, 2017

Cited in:

[Morris 2012] Ben Morris. “How to manage down the payments on your technical debt,” Ben Morris Software Architecture blog, September 3, 2012.

Available here; Retrieved December 30, 2016. This blog entry contains an assertion that controlling formation of new technical debt requires only “diligence, ownership and governance.”

Cited in:

[Morse 2004] Gardiner Morse. “Executive psychopaths,” Harvard Business Review, 82:10, 20-22, 2004.

Available: here; Retrieved: April 25, 2018

Cited in:

[Ostrom 1990] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press, 1990.

Cited in:

[Ostrom 2009] Elinor Ostrom. “Beyond the tragedy of commons,” Stockholm whiteboard seminars.

Video, 8:26 min. Apr 3, 2009. here; Retrieved December 29, 2016.

Cited in:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Wake 2002] Bill Wake. “Coaching Drills and Exercises,” XP123 Blog, June 15, 2002.

Available: here

Cited in:

[Weinberg 1985] Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House, 1985.

Ford’s Fundamental Feedback Formula. Order from Amazon

Cited in:

Other posts in this thread

Show Buttons
Hide Buttons