Legacy debt incurred intentionally

Last updated on July 11th, 2021 at 11:07 am

“The General,” a Civil-War-era locomotive, in Union Station, Chattanooga, Tennessee
“The General,” a Civil-War-era locomotive, in Union Station, Chattanooga, Tennessee. Built in 1855 in Paterson, New Jersey, for the Western & Atlantic Railroad, it is the engine stolen by Union spies in the Great Locomotive Chase. The theft was part of a plan to cripple the Confederate rail network during the American Civil War. The General is now at the Southern Museum of Civil War and Locomotive History in Kennesaw, Georgia. It originally conformed to the southern rail gauge of 5 feet (1,524 mm). But it was converted to the U.S. Standard Gauge of 4 feet 8 1⁄2 inches (1,435 mm) after 1886. Its original construction was therefore legacy debt. If it had been built after the war, it would have comprised legacy debt incurred intentionally. Photo “The General, Union Station, Chattanooga, Tenn.,” Detroit Publishing Co., publisher, ca. 1907. Courtesy U.S. Library of Congress.

Throughout this blog, I’ve been using the terms legacy technical debt and incremental technical debt. Legacy technical debt is debt that existed before we undertook the current project; incremental technical debt is debt we incurred in the course of executing the current project. But there is some incremental technical debt that’s actually legacy debt incurred intentionally.

Reviewing some terminology

As I’ve defined incremental technical debt, it’s any debt we incur in the course of the current work. That definition works well for most incremental technical debt. For example, if we recognize at the end of the project that we should have done something a bit differently, then we’ve incurred incremental technical debt. This is one of the four forms of technical debt Fowler identifies in his 2x2 technical debt matrix [Fowler 2009].

But we must be a bit more careful, because some incremental technical debt is actually legacy debt incurred intentionally.

Legacy technical debt is debt that we incurred earlier, and which we’ve inherited as part of the asset. Sometimes we’re aware of legacy technical debt; sometimes we haven’t actually realized yet that it is indeed technical debt. In any case, the technical artifacts that comprise the legacy technical debt can impose constraints on new development. Unless we retire the legacy debt, however we modify an asset must be compatible with the unmodified parts of the assets as they are.

Sometimes technical debt can be both legacy and incremental

Although the two kinds of technical debt—legacy and incremental—might seem at first to be mutually exclusive, there’s a subset of legacy technical debt that we incur in the course of executing the current project.

Here’s a physical example:

After the United States Civil War, the state of the U.S. rail system was a bit chaotic. Most of the rail lines in the northeast and western regions of the country used standard gauge rail beds: rails that are 1,435 mm (4 feet ​8 1⁄2 inches) apart. Most of the South was using a broader gauge: 1,524 mm (5 feet). These conflicting gauges comprised a legacy technical debt. The combined rail system retired that debt over a two-day period beginning on Monday, May 31, 1886, when all the southern railroads coordinated to convert from a 5-foot gauge to 4 feet 9 inches [Southern Railfan 1966].

In the years immediately before the U.S. rail system retired its legacy debt, expansion or repair of the southern rail network was necessarily compatible with the broader gauge. But the broader gauge was itself legacy technical debt. That new expansion or repair work would thus have comprised newly incurred technical debt that would have also added to the legacy technical debt. Thus, in some situations, some newly incurred technical debt can be legacy technical debt.

Here’s a software example:

A software development team is executing a project to enhance the capabilities of the Marigold product. Marigold is one product in the Garden Flowers personal productivity suite. Unfortunately, the original architecture of Garden Flowers didn’t anticipate the course that the suite has since taken. That architecture now comprises legacy technical debt. However, changing the suite architecture isn’t in the charter of the Marigold team. So they’ll be creating new technical artifacts that are compatible with the current architecture. Someday, some other team will modify or replace what the Marigold team is building now. That will happen when the company revamps or replaces the Garden Flowers architecture. Thus, some of the new technical debt the Marigold team is now incurring will join the legacy technical debt associated with the Garden Flowers architecture.

Moreover, the Marigold team might incur other technical debt in the course of its activities. That might happen if, for example, it fails to complete its task. Or it could happen if the team completes its task in some suboptimal way. In that case it will be incurring incremental technical debt that it probably should retire soon. Thus, in the same project, it would be incurring both (a) purely incremental technical debt, and (b) incremental technical debt that’s also legacy technical debt.

Why legacy debt incurred intentionally matters

Any program of rational technical debt management entails measuring—or at least estimating—the volume of technical debt incurred in the course of executing each project. The goal is to limit the debt incurred, so as to get control of the total technical debt outstanding.

But with legacy technical debt, as in the example above, we can’t always control the debt we incur. In some projects, it’s necessary to incur additional legacy technical debt because the work we do must be compatible with existing assets. We want to limit incremental technical debt, but we can’t always avoid incurring incremental debt that’s also legacy debt.

This distinction is important for both policy formulation and management intervention. For instance, if a team incurs purely non-legacy incremental technical debt, we might want to address it immediately. Or we might commit to addressing it immediately after delivery. Alternatively, suppose we can obtain good data about a particular kind of legacy technical debt that’s growing because of the need to keep new development compatible with existing debt-ridden assets. Then we can use that data to elevate the priority of retiring that legacy debt before it grows even larger.

Last words

So when we ask projects to report their incremental technical debt, we want them to distinguish between legacy debt incurred intentionally, and incremental debt that they incurred for reasons specific to the project. Having data about both kinds of incremental technical debt is a necessity if we want to take appropriate management action to maintain control of the technical debt portfolio.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.

Available: here; Retrieved: July 26, 2018.

Cited in:

Other posts in this thread

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

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

Available here; Retrieved January 10, 2016.

Cited in:

[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.

Available: here; Retrieved: July 26, 2018.

Cited in:

Demodularization can help control technical debt

Last updated on July 13th, 2021 at 10:02 am

Two shipping containers resting on a “spine car”
Two shipping containers resting on a “spine car.” Spine cars are a kind of rail car used for shipping containers. The container on the left is a so-called tank container, used for bulk cargo. Various types of tank containers are available for transporting different types of cargo. Bulk cargoes include wine, oils, ammonia, and even cryogenic liquids. The steel frame around the tank provides compatibility with the standard container profile. That profile makes the tank compatible with equipment built to handle standard shipping containers. It functions as an interface between the tank and the container-handling equipment. Photo (cc) Mr Snrub at the English language Wikipedia

Modularity is a standard design approach for complex systems. But because modularity can be be a factor in the accumulation and persistence of technical debt, temporary demodularization can help control technical debt. And longer-term demodularization can reduce the rate of accumulation of technical debt.

Modularization is a standard design approach for complex systems

Since the 1970s, modular design of systems has been de rigueur in both software and hardware. More than that, modularization has demonstrated that it’s an essential feature of maintainable, adaptable, and extensible systems [Parnas 1979] [Sullivan 2001]. And we now understand that modularization is a foundational attribute of loose coupling in systems. Loose coupling enables system designers and maintainers to work in parallel, with independence. Independent parallelism renders systems economical at levels of complexity beyond what is achievable with tighter coupling [Orton 1990].

Eliminating duplication is one reason why modularization reduces maintenance and enhancement costs. Modularization enables system designers to create a single system element that provides needed functionality to many other parts of the system. Because there is then only one copy of the system element that provides that capability, adapting it in response to new needs, or to correct defects, need be done only once.

That’s a big deal. If we provided that capability through multiple system elements, and we needed to adapt it, adaptation would be necessary for each of those elements. Moreover, the multiplicity of elements opens the possibility that we might not perform that adaptation consistently. That could create further problems. Eliminating duplication is a most useful property of modularization.

Modularization provides many other advantages. For example, modularization shortens time-to-market for new capabilities. When extending the system by adding new capability, we sometimes need access to capabilities present in existing modules. We can access those capabilities easily in modularized systems, because those modules are already in a form that makes access easy. We have no need to recreate them for the new capability we’re implementing. They exist, and they’re already tested and ready to go. In this way, modularization shortens time-to-market for new capability.

Modularization has a dark side

It’s a bit of a story to show illustrate the dark side of modularization. Let’s give a name to the modular system element for which we’ve removed all duplicates. Since it’s now unique, I’ll call that modular system element “U.” Any system element that interacts with U is now indirectly coupled to every other system element that interacts with U. And that’s where the trouble comes in.

A scenario that illustrates the problem

When implementing a new capability N, and N needs access to U, we gain the advantages described above. But suppose N needs U to do something a bit differently from what U now does. Sometimes we can extend U to accommodate N without disturbing U’s existing “client base” of system elements that already depend on U. That’s no problem. But suppose what N now needs U to do would disturb U’s client base if we implemented the changes in the way we would do it if we were starting fresh. In that case, we would need to modify all of U’s existing clients. And then we would need to re-test everything. So let’s suppose that we don’t have time or resources to do all that work. We requested the time and resources, but we didn’t receive an approval.

Instead, we found a way to extend U in a less elegant, less maintainable, but still reliable way that doesn’t disturb U’s existing clients, and does meet N’s needs. We do that instead, promising ourselves that we’ll go back someday, when we have approval for the time and resources we need. Then we would “fix” U so that it serves both its existing clients and N in the “correct” way.

A natural question

That’s one form—exactly—of what we call technical debt. In this scenario we’ve illustrated one way in which modularization leads to technical debt formation.

So a natural question arises: would it make sense instead to create a new system element—call it U2—that meets N’s needs, and also meets the needs of U’s existing client base? It would make sense, in many cases, if only they knew about U2 and if only they had the time and resources to make the change. To create such a U2 would be demodularization—that is, a violation of modularity—and that is indeed heresy. It also creates a different technical debt: the obligation to convert U’s clients to become U2 clients someday, and then to delete U. But it might be the right approach.

When would demodularization help?

Under what conditions would demodularization be sensible? Here are three possibilities.

When a new and necessary adaptation is incompatible with existing forms

The scenario above is one situation in which demodularization can help. Demodularization helps when adding new capability, or adapting to a new need, requires a change to a shared module, and that change is incompatible with the existing uses of that module. Demodularization is than a useful technique, provided that we retire with due dispatch the technical debt that results.

When retiring technical debt requires an incompatible adaptation

A second situation arises during technical debt retirement operations. During technical debt retirement, it might be necessary to alter a shared module in a way that would be incompatible with the needs of its existing client base. In that case, the approach used above can be useful. First, create a successor (“U2”) to the original shared module (“U”) in a form that isn’t burdened with the technical debt that’s being retired. Then, at the same time, or over an extended period, convert all the clients of U to use the successor U2. In the meantime, the demodularization comprises a technical debt. When the conversion is complete, the you will have retired the original technical debt. Finally delete the original shared module U, thereby retiring the demodularization.

This approach entails some risk. In the interim period before you retire U, when demodularization is still in place, U and U2 are both in use. If you need changes in U, you might need to replicate them in U2. When that happens, duplication of effort can occur. This approach is useful, though, provided the interim period of demodularization is short compared to the anticipated intervals between incidents that require alterations to both U and U2. There is risk, of course, that the resources committed to finally retiring U might become unavailable after U2 is in place. In that case, the technical debt portfolio will have expanded to no good end. To manage this risk, the artifice of secured technical debt can prove useful.

Partial demodularization helps when adaptations are focused

In some instances, portions of a shared system element—call it “U”—evolve very rapidly, while most of the rest of U remains stable. Technical debt can accumulate rapidly if the element remains unitary—that is, in one piece. However, in some cases we can segregate the rapidly evolving portion of U into a smaller unit—call it “S.” If we provide S as a separate shared system element, those portions of the system that are experiencing rapid evolution can access S separately, without disturbing the system elements that require access only to the stable portions of U.

Such segregation might require a bit of duplication There might be pieces of S that U needs, and which must therefore appear in both U and S. Likewise, there might be pieces of U that S needs, and which must therefore appear in both U and S.

But the segregation might be worthwhile, because changes in S usually require testing S and S’s clients. Testing can be expensive in time and resources. Because test coverage isn’t always 100% (read: test coverage is rarely 100%), changes in S entail some operational risk. Segregating S reduces that risk by protecting U’s clients from changes in S.

Later, when the rapidly evolving S stabilizes, you can re-integrate it into its former residence in U. Until that point, its segregation—and the attendant duplications—might constitute a technical debt.

Last words

Accepting modularization as an inviolable design principle is one cause of unnecessary accumulation of technical debt. It makes retiring legacy technical debt more difficult. Be prepared to violate modularity, but do so judiciously.

References

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

Available here; Retrieved January 10, 2016.

Cited in:

[Orton 1990] J. Douglas Orton and Karl E. Weick. “Loosely Coupled Systems: A Reconceptualization,” The Academy of Management Review, 15:2, 203-223, 1990.

Available: here; Retrieved: July 11, 2018.

Cited in:

[Parnas 1979] David L. Parnas. “Designing Software for Ease of Extension and Contraction,” IEEE Transactions on Software Engineering, vol. SE-5, no. 2, March 1979, 128-138.

Available: here; Retrieved: July 13, 2017

Cited in:

[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.

Available: here; Retrieved: July 26, 2018.

Cited in:

[Sullivan 2001] Kevin J. Sullivan, William G. Griswold, Yuanfang Cai, and Ben Hallen. “The structure and value of modularity in software design,” in ACM SIGSOFT Software Engineering Notes, 26:5, 99-108, 2001.

Available: here; Retrieved: July 11, 2018.

Cited in:

Other posts in this thread

Related posts

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

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

[Orton 1990] J. Douglas Orton and Karl E. Weick. “Loosely Coupled Systems: A Reconceptualization,” The Academy of Management Review, 15:2, 203-223, 1990.

Available: here; Retrieved: July 11, 2018.

Cited in:

[Parnas 1979] David L. Parnas. “Designing Software for Ease of Extension and Contraction,” IEEE Transactions on Software Engineering, vol. SE-5, no. 2, March 1979, 128-138.

Available: here; Retrieved: July 13, 2017

Cited in:

[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.

Available: here; Retrieved: July 26, 2018.

Cited in:

[Sullivan 2001] Kevin J. Sullivan, William G. Griswold, Yuanfang Cai, and Ben Hallen. “The structure and value of modularity in software design,” in ACM SIGSOFT Software Engineering Notes, 26:5, 99-108, 2001.

Available: here; Retrieved: July 11, 2018.

Cited in:

Other posts in this thread

Related posts

Undercounting nonexistent debt items

Last updated on July 10th, 2021 at 08:55 am

Sherlock Holmes and Doctor Watson, in an illustration by Sidney Paget
Sherlock Holmes and Doctor Watson, in an illustration by Sidney Paget, with the caption, “Holmes gave me a sketch of the events.” In 1892 The Strand magazine published this illustration to accompany a story called “The Adventure of Silver Blaze” by Sir Arthur Conan Doyle. It’s in this story that the following dialog occurs:

Gregory (Scotland Yard detective): “Is there any other point to which you would wish to draw my attention?”

Holmes: “To the curious incident of the dog in the night-time.”

Gregory: “The dog did nothing in the night-time.”

Holmes: “That was the curious incident.”

From this, Holmes deduces that the dog’s master was the villain. This is an example of looking for what isn’t there, and failing to notice it. It’s an example of absence blindness.

Original book illustration, courtesy Wikimedia Commons.

People and companies are developing technologies for assessing the nature and volume of technical debt borne by enterprise assets. The key word is developing. Some tools do exist, and they can be helpful. But they can’t do it all. Most assessments also rely on surveys and interviews of engineers and their managers. But these tools have limitations, too. Among these limitations is undercounting nonexistent debt items in surveys about technical debt.

It’s well known that survey results can exhibit biases. Collectively, these biases are known as response biases [Furnham 1986]. Sources of response bias include phrasing of questions, the demeanor of the interviewer, the desires of the participants to be good experimental subjects, attempts by subjects to respond with the “right answers,” selection of subjects, and more. These sources of bias are real, and we must address them when we design surveys.

Selection bias and absence blindness

But I have in mind here a set of biases more specific to technical debt. For example, when we ask subjects for examples of technical debt, they’re more likely to recall and provide examples of artifacts that exist than they are to provide examples of artifacts that don’t exist. This happens because of a cognitive bias called selection bias. The effect isn’t intentional, and it can dramatically skew results.

Selection bias is an example of a cognitive bias. In this case, selection bias acts to skew the data in such a way as to interfere with proper randomization, which ensures that the sample data doesn’t accurately represent the actual population of technical debt artifacts. Specifically, the data will tend to under-represent technical debt artifacts that don’t exist. Related phenomena are absence blindness and survivorship bias.

For example, regression testing is an essential step used in refactoring systems. When regression tests are unavailable, and we try to refactor a system to retire some of its technical debt, we face a problem. We can’t be certain that we haven’t changed something important. And so, when a survey design doesn’t mitigate the effects of selection bias, we can expect an elevated probability of failing to note any missing regression tests.

Mitigating the risk of undercounting nonexistent debt items

It’s helpful for surveys to include questions that specifically ask subjects to report technical debt items that don’t exist, but which would be helpful if they did exist—like missing regression tests. Even more helpful: conduct brainstorming sessions for engineers in which the goal is to list missing artifacts, tools, or processes that comprise technical debt precisely because they’re missing.

References

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

[Furnham 1986] Adrian Furnham. “Response bias, social desirability and dissimulation,” Personality and Individual Differences 7:3, 385-400, 1986.

Cited in:

[Orton 1990] J. Douglas Orton and Karl E. Weick. “Loosely Coupled Systems: A Reconceptualization,” The Academy of Management Review, 15:2, 203-223, 1990.

Available: here; Retrieved: July 11, 2018.

Cited in:

[Parnas 1979] David L. Parnas. “Designing Software for Ease of Extension and Contraction,” IEEE Transactions on Software Engineering, vol. SE-5, no. 2, March 1979, 128-138.

Available: here; Retrieved: July 13, 2017

Cited in:

[Southern Railfan 1966] Southern Railfan. “The Days They Changed the Gauge,” 1966.

Available: here; Retrieved: July 26, 2018.

Cited in:

[Sullivan 2001] Kevin J. Sullivan, William G. Griswold, Yuanfang Cai, and Ben Hallen. “The structure and value of modularity in software design,” in ACM SIGSOFT Software Engineering Notes, 26:5, 99-108, 2001.

Available: here; Retrieved: July 11, 2018.

Cited in:

The Principal Principle: Focus on MICs

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

The door to a bank vault
The door to a bank vault. One way to know that technical debt differs from financial debt is that banks aren’t involved in any way. Treating technical debt as if it had anything in common with financial debt—beyond our own sense of obligation—is a shortcut to real trouble. Remember the Principal Principle.

When some organizations first realize that technical debt is limiting their performance, they begin by chartering a “technical debt inventory.” They try to determine how much technical debt they’re carrying, where it is, and how much retiring it would cost. They really want to know how fast they can retire it. That’s understandable. It’s not too different from how one would approach an out-of-control financial debt situation. It might be understandable, but in most cases, inventorying all technical debt is ineffective. For technical debt we need a different approach, because technical debt is different from financial debt. With technical debt, we must be follow what I call the Principal Principle, which is:

The Metaphorical Principal (MPrin) of a technical debt, which is the cost of retiring it, isn’t what matters most. What usually matters most is the Metaphorical Interest Charges—the MICs.

Why MICs matter more

MICs on technical debt can vary dramatically. For assets that aren’t undergoing maintenance or enhancement, the MICs can be Zero for extended periods. And for retiring assets, any technical debt they carry can vanish when the asset passes out of service. For other assets, MICs can be dramatically higher—beyond the total cost of replacing the asset.

Most people regard the sole effect of MICs as reduction in engineering productivity. I take a different approach. I include in MICs anything associated with technical debt and which depresses net income. That would include lost or delayed revenue, increased expenses—anything. For example, suppose technical debt causes a two-month delay in reaching a market. IN that case, its effect on revenues can be substantial for years to come. I regard all of that total effect as contributing to MICs.

So the Principal Principle is that a focus on Principal can be your undoing. Focus on MICs instead. Drive them to Zero and keep them there.

Other posts in this thread