Figure 3: Common costs or consequences of technical debt.
Putting it all together
For some software professionals, enumerating lists of causes and effects of technical debt is helpful, but not enough to build a strategy for reducing and preventing technical debt. Which of the causes is the most common? Regardless of what happens in other organizations, which cause is the most important for us? How can we paint a picture of how technical debt is hurting us that people throughout the organization can understand?
For these reasons, we will take the next step in treating technical debt as a systemic problem. We will use the concepts and tools developed for understanding the behavior of systems in general to address the conundrums of technical debt. We will show how to use systems theory to depict the system as a whole, including the interactions among the parts of that system that contribute to technical debt, or suffer because of it.
Painting a systemic picture of technical debt
Treating technical debt as a systems problem has its greatest value at three moments:
- The identification of the most significant causes and consequences of technical debt.
- A plausible estimate of how likely different strategies for dealing with technical debt are to succeed.
- A more informed conversation among the people who contribute to, or are affected by, technical debt.
To make these moments a reality, we have to delve a little more deeply into systems theory.
From a perspective to a model
As we have seen in the previous discussion, systems analysis provides a language and a mindset for describing the technical debt problem in meaningful and precise terms. Systems modeling is the chief tool for creating this picture: the model tells us not only what aspects of the system deserve the most attention (for instance, pressures on the team, the average skill of developers, etc., lower productivity, etc.), but also how they interact. These interactions are as important as the system components themselves.
Why should you learn systems thinking, or the special language of systems modeling?
- Dynamic systems are more than a list of causes and effects. A list of causes of technical debt is only useful to a point. The list is like a box that contains pictures of eyes, ears, a mouth, a nose, a hand, and other pieces. Only when you assemble the whole picture can you see the Mona Lisa.
- Systems modeling identifies the critical factors behind problems. A list of causes does not tell you which among them is the most pernicious source of technical debt. A systems diagram, on the other hand, can show you that the same cause contributes to multiple effects, making it an obvious first target for technical debt reduction efforts.
- Systems modeling avoids scapegoating. One of the most important outcomes of systems analysis is that it reduces the amount of unfair finger-pointing. Individuals may want to be “good citizens” about technical debt, but the system in which they work makes it difficult for them to do the right things.
- Systems analysis provides a common, well-established, well-proven language that everyone in the organization can understand. Executives, business users, and other people who inadvertently contribute to technical debt, or feel its effects, have little patience or interest in learning about cyclomatic complexity or naming conventions. They can understand a relatively simple picture that shows how, for example, over-commitment encourages technical debt, which in turn undermines the ability to meet future commitments.
A simple model of an over-committed team
Over-commitment will be the starting point for our brief primer on using systems modeling to understand technical debt. We will start with a very simple system that consists of two "stocks," a systems modeling term for quantities that we want to track within a system. In this case, the stocks are a backlog (unfinished work) and code in production (finished work). The rate at which work items move from the former into the latter is, of course, the development team's velocity. If the world were as simple as this diagram, the team would steadily move work items from the backlog into production at a fixed rate (with some natural, minor fluctuations.
Figure 4: A simple model of a software team.
Of course, the world isn't that simple. We will introduce two variables into this picture:
- Deadline pressure. The team is under pressure to meet some highly aggressive targets. In fact, the team is overcommitted: It cannot meet these targets without cutting corners.
- Technical debt. Cutting corners means accruing technical debt. Once the deadline pressure exceeds the team's ability to meet its commitments without accruing technical debt, additional pressure produces technical debt at a higher rate.
To illustrate the connection between these two variables, we draw an arrow between them. The plus sign (+) indicates a direct correlation between these variables: as deadline pressure rises, so does technical debt.
Figure 5: The deadline pressure component of our sample model.
Now we will connect technical debt to the work of the team. We draw another arrow between technical debt and the team's velocity. We use a minus sign (-) to indicate an inverse relationship between these two elements of the system: as technical debt goes up, velocity goes down.
Figure 6: Deadline pressure and technical debt added to the model.
Finally, we will add a third relationship. By drawing a line between velocity and deadline pressure, and marking it with a minus sign (+), we are saying that deadline pressure pushes the team to increase its velocity. However, over time, as technical debt mounts, velocity will actually decrease.
Figure 7: Further additions to the model, showing a positive feedback loop of lowered velocity, higher deadline pressure, and greater technical debt.
Here, we have drawn a simple picture that would make sense to programmer and customer alike. After a certain point, the more pressure the customer puts on the development team, the less productive the team becomes.
This simple model leads to some even more dark conclusions. There is an unspecified limit to the number of corners that the team can cut. Therefore, further pressure is meaningless, once the team is maximizing technical debt. Velocity will continue to drop, however, so the system never reaches a stable equilibrium. There are only two ways to fix the damage that this positive feedback loop creates: (1) removing the pressure to give the team enough time to clean up technical debt to an acceptable level; or (2) pulling the plug on the project. Unfortunately, stakeholders often see both alternatives as unacceptable, which lets this system continue to spin out of control. Eventually, circumstances will force one of these decisions on those stakeholders, at a much higher price tag than if they had intervened earlier.
Identifying destructive relationships
Systems modeling helps to identify risks, often seen in destructive patterns of behavior that get triggered when the system enters a particular state. In the diagram below, team discipline about good coding practices is the bulwark against technical debt. Once outside pressures damage that discipline, a nasty positive feedback loop starts. Technical debt mounts, making it harder to work in the code. Team morale drops, making people more cynical about their work, further eroding team discipline.
Figure 8: A different model, incorporating team morale and discipline into the picture.
Turning a model into a simulation
We could take an additional step in modeling a system like our “iron triangle” of deadline pressure, technical debt, and team velocity. Using a tool to simulate how the system works, we can see what outcomes result from our decisions, such as taking a hard line against technical debt. We would need to add some specifics, such as the team's velocity, the impact of technical debt on that velocity, the size of the backlog, and so on. Once we do, we can use an open source or commercial systems modeling tool to watch the system in operation. If the model is simple enough, we can also create a game, based on the model, which we can use as a test bed for different strategies for dealing with technical debt.
Simulation can lead to further conclusions that have important practical consequences. For example, you might discover that there is a take-off point for an uncontrolled spiral into massive technical debt. Once deadline pressure rises to a predictable level, the team will be cutting corners at an increasingly frantic rate. Learning how to avoid this death spiral would be one of the key lessons from just such a simulation.
Simulation also creates a more realistic sense of the causes and consequences of technical debt. For example, a simulation may show you that some countermeasures, such as code review, may have more or less impact than expected. Running the simulation several times also reduces the chance that one particular outcome, either in the simulation or in real life, represents an unlikely outlier event, not the most likely outcome that you might expect to get from, for example, budgeting time in each sprint for technical debt reduction. Simulations also show the delayed effects, such as when the time budgeted for technical debt reduction needs several sprints to start really paying off.
Deciding on the essentials
Systems analysis can generate complex models easily. Fortunately, you don't need that complexity to make good use of systems thinking. Every model tells a story, and that story won't be the same everywhere. In one organization, the root cause of technical debt might be deadline pressure; in another organization, it might be poor engineering practices. In one organization, the chief cost of technical debt might be reduced velocity; in another, it might be unreliable plans.
Systems analysis provides a canvas and a set of implements for making a precise description of how technical debt hurts your software innovation efforts. While it can be valuable to see, in operation, all the causes and effects that may be important, an all-encompassing model does not tell you which causes and effects have the greatest relevance in your organization. Therefore, you have to use systems analysis to tell your own story.
That being said, a complex model that describes the common relationships in a software innovation system struggling with technical debt may suggest elements of your story that merit greater emphasis. For example, you might not consider team morale to be a critical factor, until you see a model in which team morale matters enormously for both preventing and reducing technical debt.
For that reason, we have provided a more complex model for your edification. Since it has many moving parts, we have written a companion document to explain the components and relationships that comprise the model. For more information, see Thierry's model. 
Patterns, principles, and archetypes
The more complex model has an additional benefit: it contains patterns that are common in organizations struggling with technical debt. The two types of patterns that emerge from this type of analysis, systems principles and systems archetypes, will both help to master technical debt.
Systems principles are general guidelines for understanding how systems work. By extension, they are ways of developing realistic expectations about dealing with systemic problems like technical debt. Here are a few examples:
- Systems behave in unexpected ways. To return to an earlier example, the usual way to measure the cost of technical debt is lower productivity. There may be other consequences that are more important, such as the damage that technical debt can inflict on sprint and release planning, portfolio management, and flow. Unless you looked at technical debt in light of the larger system of software innovation, you might miss these bigger costs.
- Causes do not have linear effects. For example, people facing severe technical debt burdens sometimes lament, "If only we had better developers." Hiring top-rank developers, however, might not bring the relief expected. More talented developers might help avoid technical debt, but not help dispel the existing debt. Cleaning up other people's debt is a thankless chore that some top-notch programmers might prefer to avoid, reducing the value of investing in them.
- Causes do not have immediate effects. The delay between cause an effect can lead to all kinds of false conclusions. For example, instituting code review might not have a significant impact on technical debt for several sprints, until new disciplines take hold. Delayed effects often lead people to over-correct when they appear. For instance, a few sprints after implementing an open source module, the team might experience a reduction in velocity. The problem might not be technical debt in that module, but just the team's inexperience working with that unfamiliar code more frequently.
Systems archetypes are the product of past experience analyzing other systems, then anticipating certain behaviors of the current one under the microscope. In many cases, systems analysis can identify these patterns across systems that superficially appear to be unlike, but share some important commonalities. Here are a few examples, again showing their relevance to technical debt:
- The tragedy of the commons. When people who use or contribute to a resource do not share responsibility for its maintenance, the system suffers from neglect. You often see this problem in development teams off-load maintenance work to other teams, in which case, the perceived responsibility for preventing technical debt is much lower.
- Limits to success. In this pattern, success leads to a limiting condition that blocks further progress. For example, a team might negotiate with its management permission to devote some time to technical debt reduction. However, after reducing technical debt measures by a noticeable degree, management pulls the plug on further efforts. Unfortunately, both management and the team were looking at the wrong measure. Instead reducing the number of copied code blocks and overly complex classes, the real measure of success was increased team productivity.
- Drifting goals. Instead of trying new approaches to addressing a problem like technical debt, people may lower the bar for success. This pattern is especially common in dealing with technical debt, which requires some experimentation to discover the best collection of techniques to both prevent and reduce technical debt for a particular code base, team, and organization. After trying a single approach and not getting the desired results, teams may retreat from their technical debt containment goals.
When faced with a problem like technical debt, the temptation is to take linear, direct, and narrowly focused approaches. If only we weren't so sloppy in writing code...If only we spent more time mentoring our junior developers...If only we had less pressure on us... By treating technical debt as a systemic problem, we are more likely to understand its causes, and deal with its effects.
- The major causes and effects are identifiable. Most of the causes of technical debt are not as immediate as the callous disregard that a careless developer takes when writing code. The real causes lie elsewhere, in the team, the value stream, and the larger organization. The real consequences lie in these other planes, too: while we might sympathize with the plight of an unhappy programmer trying to work with technical debt-ridden code, we suffer substantial financial consequences of technical debt-ridden parts of our software portfolio.
- By plugging these causes and effects into a system model, you can better assess the problem and plan next steps. Until you create a picture of the system of software innovation, it is difficult to tell how effective corrective measures will be. While some degree of code hygiene is always a good thing, taking a particular step, such as running regular static analysis tests, or implementing code review, may not be as effective as other measures.
- Systems thinking naturally involves people outside the team in addressing technical debt. "We need time to clean up some problems with the code, so you'll just have to trust us," is a far less effective message than, "Here is the picture of how you unwittingly contribute to technical debt, and the hidden costs of living with it." The picture of the whole system, not just the report from a tool like Sonar, is the real starting point for discussion of how to deal with technical debt.
Tables and figures
The following tables and diagrams appear in this document:
Figure 1: Indirect and direct causes of technical debt. 3
Figure 2: Common causes of technical debt. 4
Figure 3: Common costs or consequences of technical debt. 5
Figure 4: A simple model of a software team. 7
Figure 5: The deadline pressure component of our sample model. 7
Figure 6: Deadline pressure and technical debt added to the model. 7
Figure 7: Further additions to the model, showing a positive feedback loop of lowered velocity, higher deadline pressure, and greater technical debt. 8
Figure 8: A different model, incorporating team morale and discipline into the picture. 9
 For a full explanation of technical debt, see “Introduction To The Technical Debt Concept” at https://www.agilealliance.org/introduction-to-the-technical-debt-concept/.
 Therefore, in this paper, we will focus on the sources of technical debt that result from a lack of disciplined coding, recognizing that some marginal technical debt creation happens in any case.
 Dice Of Debt is available at https://www.agilealliance.org/dice-of-debt-game/.
 Two of the most notable applications of systems thinking in software development include Gerald Weinberg, An Introduction To General Systems Thinking, and Grady Booch, Object-Oriented Analysis And Design With Applications.
 Some good introductions to systems analysis include Donella Meadows, Thinking In Systems: A Primer; George Klir, Facets of Systems Science; and the Systems Thinking Wiki at http://systemswiki.org/index.php?title=Main_Page.
 For the most immediate measures of technical debt – how each type of code quality problem contributes measurably to a loss in productivity – see the Agile Alliance Debt Analysis Model (A2DAM) at https://www.agilealliance.org/the-agile-alliance-debt-analysis-model/.
 For a good discussion of how to budget time for refactoring, see Greger Wikstrand’s blog post, “Budget For Technical Debt Reduction,” at http://www.gregerwikstrand.com/technical-debt-reduction/.
 For an overview of systems modeling, see Hiroki Sayama, Introduction To The Modeling And Analysis Of Complex Systems.
 The more complex model includes elements that do not appear in the simple model we developed here in this document. Therefore, expect to see a different set of assumptions and relationships when reviewing that model.
 One of the most familiar applications of systems archetypes to business challenges can be found in Peter Senge’s The Fifth Discipline: The Art And Practice Of The Learning Organization.