Chapter 10. What Causes Technical Debt?
Understanding the causes of technical debt is key to successfully controlling it. In this chapter, we examine the causes of technical debt that are common across many teams and organizations. These causes are associated with the business, change in context, development process, and people and team. Enabling development teams to clearly communicate about technical debt and selecting the right analysis techniques to focus on the concrete technical debt items that are accruing interest can empower teams to take action.
The Perplexing Art of Identifying What Causes Debt
When software professionals have a name for their pain, they are eager to talk about technical debt and look for causes. Getting to the root cause of technical debt can be a daunting task. Especially in long-lived systems, technical debt accumulates in several ways. Speculating about the project characteristics and organizational environment that contribute to technical debt very quickly becomes a frustrating and useless exercise for both software developers and managers.
Talking about their massive technical debt burden is almost like a therapy session for many software professionals. We have been there. We know how it feels! And we have heard the following proclamations from practitioners:
“We have technical debt because our manager did not authorize us to migrate the system to the cloud!”
“We have technical debt because the customers keep changing their minds!”
“We have technical debt because we don't know how to hire good developers!”
“We have technical debt because we skip proper unit and automated testing when we are in a rush to finish a release!”
“We have technical debt because we had no idea that we would need to scale up so soon!”
We know it feels good to get it out of your system, but as you talk about it, the debt keeps building. Talking about who failed is not sufficient to do anything about it. An important step toward getting ahead of technical debt is to understand the realities and complexities of software development that cause the debt. While understanding the causes will not provide a direct path to the precise location of the actual debt, it will provide a map of the environment and help you decide where to start looking more carefully. More importantly, it will help you eliminate future occurrences. Recall two of the principles we already introduced:
Managing technical debt is not a one-time activity; it is an ongoing, integral part of the software development lifecycle. In this chapter, we discuss moving from a possibly speculative cause to a descriptive cause and the potential for injecting more technical debt into the system. This is the period leading up to the occurrence of technical debt in the timeline depicted in Figure 10.1. Software developers often confuse the causes that lead to accumulation of technical debt with the system artifact that has the debt and that should be fixed. You need to understand both the causes and the system artifacts, sometimes together and sometimes separately. We already talked about how to approach the most essential development artifacts of code, architecture, and production infrastructure in Chapters 5, “Technical Debt and the Source Code,” 6, “Technical Debt and Architecture,” and 7, “Technical Debt and Production.”
Having a good understanding of the causes of technical debt will later help you investigate its impact on the system and identify the areas of the system that will need to change. A suitable description of a cause will enable a team to articulate concrete actions to take, which include eliminating the cause, deciding how to analyze and tackle the debt, and possibly making broader changes in the organization and its processes. The ultimate goal of effective technical debt management is to reduce the unintended causes of technical debt and create an environment in which technical debt occurs mostly because it was taken on for a deliberate business need.
The Roots of Technical Debt
In most horror stories about technical debt, the debt resulted from a combination of causes that built up to big problems. Unfortunately, we have seen far fewer examples of the debt that one consciously takes on, knowing all the terms of the debt, and having a strategy for paying it back, such as in buying a house.
Unintentional Debt
The causes of unintentional debt often confuse software development teams. These causes range from incompetence and reckless development behavior, to small inadvertent actions that result from lack of discipline and planning, to just not knowing any better. Most issues related to code and design quality have their roots in unintentional debt. Software developers and managers do not choose to introduce this technical debt; they do so accidentally. Symptoms emerge much later in the software development lifecycle, so the causes are hard to track down. Teams do not know when or how the debt began and, worse, they don't know how to get rid of it.
Intentional Debt
Managing technical debt with intention is a resource- and value-optimization activity, most often conducted to achieve a time-to-market goal. The causes of intentional debt are clear to the development team. This team has a business goal to satisfy within a short time frame: a release for a new customer, a feature to add that will let the product leapfrog the competition, a demo for prospective investors, or some other opportunities. Intentional debt involves careful and deliberate decision making by software developers and managers. At some point, they decide to introduce technical debt to achieve some objective. This intentional debt can be short term, when developers intend to rectify the technical debt within the next few releases. Or it could be long term.
When Ward Cunningham first used the debt metaphor in 1992, he implied intentionality. He used the example of shipping a system to a customer for the first time:
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.” The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
What Causes Technical Debt?
A key aspect of any successful technical debt management strategy is to recognize that a cause contributes to the occurrence of technical debt in the system, and the cause is not the technical debt itself. To manage technical debt strategically, you must understand what led the technical debt to accumulate in the first place.
We sort the causes of technical debt into four major areas (see Figure 10.2):
Nature of the business
Change in context
Development process
People and team
These are the causes we've identified, though there is great variability from project to project, and technical debt items are not evenly spread among the categories. And we do not claim to provide an exhaustive list, although we are pretty confident that we have included a significant number of common causes. When teams talk about causes, they often foreshadow, even if only in general, the actual technical debt items or symptoms as well. As we present sample scripts from Atlas, Phoebe, and Tethys, we will highlight the causes, symptoms, and potential technical debt items. The challenge these organizations faced initially was not always understanding what technical debt items resulted from these causes. You might find similar discussions in your organization as you start to implement technical debt management practices.
Causes Rooted in the Business
Business goals, requirements, resources, the amount of risk the organization is willing to take, and other business pressures all influence a product. Business problems cause technical problems that lead to technical debt.
Time and Cost Pressure
Development teams most often go into technical debt because of resource pressures, which usually boil down to time and developer costs in software development projects. A senior developer at Atlas described the nature of the time and schedule pressure in her project as customer-driven business pressure:
Our customers and business leaders care only that we introduce new functionality to the users rapidly (cause). The customer gives almost no thought to what functionalities the users will need in the future or a vision for the end-game system. The customer's view is short-sighted and completely focused on tactical, immediate needs. So instead of taking the time to build a service layer for common functionality, we keep adding these services all over the system (potential technical debt).
Who would disagree that such constraints have demotivating and draining effects on a team? Defining success as delivering the required functionality within budget and schedule (fixing all three points on the classic quality triangle of scope, cost, and schedule) results in individual developer decisions that compromise intrinsic quality and introduce technical debt. The agile software development movement was born as a reaction to this problem and has succeeded in overcoming it to some extent by featuring communication with the customer early and often about value, quality, and constraints.
In this situation that Atlas is trying to manage, the developer recognized that the development artifact associated with technical debt is not the time and the cost pressures. It is the design decision to skip extracting common functionality to a service layer when developers are rushing against deadlines. And it is the flimsy software that results as functionality is instead repeated in multiple places.
Misalignment of Business Goals
Is your product solving the right problem for the business? A technical lead in the Phoebe project shared this example of technical debt in reference to a much-needed effort to change the technology stack to support portability:
Poor business knowledge (cause) led to poor system design (potential technical debt), which led to poor user experience (symptom), which in turn led to a large amount of rework (symptom). And, most importantly, it led to the need to regain user satisfaction and acceptance of the system—I mean acceptance in the sense of the users agreeing to use it, not buyers’ acceptance.
This is a clear case of “garbage in, garbage out.” When the business side of the company does not understand the technical underpinnings of the system development or the business environment, the resulting problems in the system cannot easily and simply be resolved by labeling them as technical debt.
Lack of clear business goals inevitably will lead to technical debt when the asdesigned-and-implemented system functionality and the expectations of the market do not match. A case like this example from Phoebe requires understanding the business priorities first and then tackling the system redesign.
Requirements Shortfall
Not articulating detailed requirements, not implementing expected functionality, and not understanding architecturally significant requirements such as security, performance, and availability that crosscut the system will all cause technical debt. The quality assurance manager from Tethys, the global giant, had to deal with this firsthand:
A lot of business requirements from different divisions (cause) were implemented in an unstructured way (potential technical debt), which caused a lot of trouble with data flow (symptom). The system is a lot more complex than it should be (potential technical debt).
More often than not, developers respond to ambiguous and poorly understood requirements by either making narrow choices for the limited requirements they do understand or making overly general choices in the hope of anticipating the eventual requirements. Both responses add complexity that makes changing the system more costly.
However, these multiple issues with the requirements are not technical debt. A case like this example from Tethys requires first understanding the requirements and then understanding the problems it causes in the system and the complexity of the system that makes it costly to address these problems. Only then is it possible to start articulating the actual technical debt.
Causes Arising from Change in Context
Technical debt is a time-related concept. A design choice that did not create any technical debt at the time the decision was made can trigger re-architecting when the system context changes. This re-architecting is the result of technical debt that is caused by a change in business or technology or by natural evolution. Phoebe experienced this technological gap (introduced in Chapter 2, “What Is Technical Debt?”) as the team started partnering with larger healthcare providers. Team members realized that their choice of a web services stack created a significant number of incompatibilities. They faced a hard decision to reconsider their design after almost three years of development.
Change in Business Context
Unanticipated external events create unanticipated changes in business goals. All the decisions for a system can be appropriate at the time they were made, but in many cases when the business context changes, they simply do not apply anymore. We could list countless examples: Introduction of the iPhone shook up the telecommunication market; advances in cloud computing facilitated infrastructure, platform, and Software as a Service models and shifted computing resource allocation priorities; and the open architecture initiatives by governments made some proprietary internal efforts obsolete.
When faced with such extreme changes, the right approach is not to ask, “How do we tackle our issue log?” The right approach is to ask, “Which of our business drivers will change in this new world? Which of these business drivers will require products to change?”
Technology Change
Technologies change—some at an anticipated rate and some in disruptive ways—triggering business changes. Lock-in to particular software, hardware, or middleware technology eventually will limit design options and accumulate technical debt in the form of unanticipated rework. Similarly, delays in upgrading technology, hence getting out of sync with the most recent version available, can create issues down the line. In fact, version mismatch is cited as one of the top causes of unanticipated security issues that create financial drains for organizations. Such mismatches often result in significant re-architecting efforts that might necessitate that entire releases be devoted to reducing technical debt, since a simple patch update will not do the trick. A wise approach is to plan ahead for technology change, balancing adaptation with anticipation and building those estimations into the system. How much cost you are willing to bear to anticipate future changes often depends on the level of uncertainty of future change. The more uncertain future changes are, the more it might make sense to adapt as you go and make changes as needed.
Phoebe's experience illustrates the cost of a technology change. As the Phoebe product increased its customer base, team members quickly realized that their earlier choice of web services stack created technology lock-in and limited their deployment options. The initial web services stack was an intentional design choice, or known technical debt, that would allow the product to be released quickly. Then new customers created a need for broader deployment options, which increased the amount of debt beyond the initial value of the original design choice (the tipping point in our timeline). This triggered payment to take higher priority: The development team needed to replace the web services stack with a technology choice that addressed broader requirements for Phoebe.
Natural Evolution
Systems age. As part of this natural evolution, systems change as they are maintained and new functionality is introduced. Such changes can eventually cripple a system. The consequence of such natural evolution, the increasing pervasiveness of software, and the sociotechnical complexities of creating software produce technical debt. We captured this as a principle that summarizes the unavoidable nature of technical debt:
A robust approach for managing technical debt that provides teams with effective tooling and incentivizes them to talk about technical debt and factor it into development plans can help mitigate the unavoidable effects of system aging. This is similar to healthy living, where making good choices about nutrition, exercise, and a supportive social environment will result in improved longevity and health. Understanding technical debt practices is similar. We address this phenomenon in Chapter 13, “Living with Your Technical Debt.”
Causes Associated with the Development Process
Developers and managers often categorize flawed ways of executing software engineering practices and processes as technical debt. While team members might have problems following such processes, improving the processes will not fix the technical debt that has accrued in the system. Effective technical debt reduction involves understanding how undisciplined ways of executing processes influence the system, create unintentional system complexity, and result in technical debt. Preventing new debt from occurring requires a focused strategy, an organization process-improvement initiative, or both. There is plenty of available information about process improvement and how to choose and follow a sound software development process.
Ineffective Documentation
Documentation, in particular architectural design and test documentation, is often the elephant in the room. Existence of system documentation does not ensure that the system will be free of technical debt. The documentation must be effective: accessible, pertinent, and up to date. Ineffective or insufficient documentation creates a risk that the system will incur technical debt. An initial small group of developers, under pressure to deliver, will not see much value in spending time and effort documenting some of their design choices, constraints, guidelines, APIs, and other details. Subsequent developers may hesitate to change code that they are not confident they understand. Here is a situation from the Tethys project, as described by one of the developers:
A portion of our product had little to no architecture documentation or descriptions of test procedures, and it was riddled with bugs (cause). The little documentation that existed was so outdated that it was not useful at all. Lack of acceptance of these facts, coupled with an overriding desire to maintain a schedule, led to a release that the customer rejected (symptom). The subsequent investigation and resolution of this problem required us to generate the design documentation that we should have created and maintained all along. It cost us months of time to re-create. Only after that effort were we able to locate where the problem was in the system (technical debt).
This developer articulates very clearly the impact on the system from the lack of clear, up-to-date, and usable documentation. Ineffective documentation often results in challenges in tracking existing issues, understanding their consequences, and preventing them from incurring more debt. Combined with schedule pressure, injection of new issues into the system becomes inevitable. It is likely that several causes are active simultaneously, as Tethys experienced. Creating the needed documentation did not resolve the project's debt, but it did provide a resource for the team to pinpoint the problems in the system.
Documentation becomes more important as a system experiences more success and the organization adds more people to a team. Without effective documentation, the process of bringing in the new team members becomes longer and more error prone. There is a limit to “the code is the documentation,” especially when the codebase grows large and when designers need to communicate key architectural decisions. Some of the subtler design decisions are indeed embodied in the code, but they might not be obvious to the readers of the code. This is the case, for example, in a choice not to use a certain package or a certain feature of a library. The reasons against a choice do not appear in the code and, if they are not documented, the rationale is lost to members of the development team who weren't involved in the decision.
Because the Tethys team hires new developers frequently, lack of documentation creates an especially high risk that they will contribute to technical debt. A member of the Tethys team explains as follows:
Documentation is spread over a set of Word/Excel documents and about four Application Lifecycle Management (ALM) database projects (cause). Helping someone new understand the product specification is very difficult because the details are hard to find.
A reasonable goal is to document for the needs of the reader, focusing on just enough documentation rather than documentation for the sake of process.
Insufficient Testing Automation
Test automation becomes especially critical when subsequent releases of a system add more and more functionality that begins making the original features erroneous. Adding new code can break code that originally worked as intended. Development teams focus on testing what they develop for the current release and not what they developed for previous releases. As a result, they introduce inconsistencies throughout the system that cause rework in the codebase, build scripts, and test suites. It takes a lot of effort to capture test cases systematically and instrument them in a form that can be run against the system in an orderly fashion with tools.
At the extreme, the absence of automated acceptance or regression testing is a major cause of technical debt. In 2004 Michael Feathers even defined “legacy code” as “code without tests” or code that has little or no automation in running these tests. Absence of regression tests is also a major obstacle in technical debt remediation: Developers are concerned that refactoring may adversely affect the system's behavior and introduce undetected defects. Therefore, they may prefer to live with not-quite-right code that does the job rather than improve the internal structure of the code at the risk of altering its behavior.
Testing that is not aligned with the product goals can lead to over- or undertesting.Testing that is not relevant to the product can lead to unproductive work or developers ignoring the results, as described with the indiscriminate use of static code analyzers discussed in Chapter 5. Knowledge of business goals, requirements, and architectural risk is needed to guide analysis and testing of the system.
Automated testing has a multifaceted influence on technical debt management. An effective testing strategy, in particular for automated unit testing and regression testing, will influence the system design and uncover issues that may turn into technical debt in the long run. The following two scenarios described by an Atlas developer demonstrate this duality vividly:
Scenario A: Building the automated testing infrastructure
We were not able to fully stand up our automated testing at the beginning of the project (cause). As development proceeded, the volume of features to be tested grew until the automated testing infrastructure was fully implemented (symptom). Even after clearing this backlog, new features and changes resulted in some older tests requiring rework so they would continue to pass (potential technical debt).
Scenario B: Building tests to catch issues and ensuring there is sufficient automated unit testing
Test coverage of the application wasn't fully assessed, and the sole test resource was removed earlier than anticipated(cause). Automated unit tests weren't completely defined. Developers were expected to perform adequate testing of their teammates' code but weren't always able to do this as thoroughly as they needed to because they were under tight time constraints to release the application. Consequently, we found ourselves overwhelmed with unexpected defects that the users kept finding (symptom). The root cause of these still lingers in the system (potential technical debt).
Scenario A describes an example of a technical debt item that introduced rework and needed to be fixed. The nuance in Scenario A is that it describes a causal chain that begins with the lack of automation that results in rework items in both the tests themselves and in the system due to misalignment between the tests and code (which we explored in Chapter 7). Scenario B also describes a chain of causes and their consequences. It is similar to ineffective documentation. When the tests did not exist, the developers did not catch unanticipated errors introduced into the system in a timely manner, which caused technical debt to accumulate. Similarly to documentation, testing often is present but may be very ineffective.
The goal of managing technical debt is to tease apart the root causes (in this case, lack of automation) from the technical debt development artifacts (reworked features and tests). Distinguishing these is necessary to devise clear remediation strategies for removing the debt.
Misalignment of Processes
All software development teams use processes. Members might deviate from the processes, which can cause technical debt. We refer to this deviation as misalignment of processes. Addressing the consequences of technical debt that result from misalignment of processes may require multiple actions at both the product level and the organization level. The Tethys developer who offers the following insight understands the difference between reckless, inadvertent practices that could and should be avoided and the strategic, intentional underpinnings of technical debt:
Delays in our project are due to creeping requirements, insufficient resource allocation, and interdepartmental disagreements—and all these are due to poor process management and cause technical debt (cause). We should fix our process but also do a deep system analysis to understand our current technical debt.
The process used by developers could be well defined, such as Scrum, Rapid Application Development, or Scaled Agile Framework®. Or it could be a homegrown and implicit process with less-defined activities and roles. In a small team, members would not need an elaborate process description but would likely have some tribal knowledge of how they develop a system. Issues start arising when teams do not buy into the selected processes or do not understand them well.
Examples can range from simple oversights such as not checking the approved list of features with the customer (hence developing the wrong feature set) to not following the development procedures for checking in only tested code or pulling tasks from the backlog. Creating a common understanding of and getting buy-in for the procedures to follow among the team members will help them avoid unintentionally accumulating debt.
Causes Arising from People and Team
One of the critical and often overlooked influences on system development is the people developing the system. People make decisions, people implement the systems, and people use the systems. There are countless examples of ineffective teams or developers having widespread impact on a system that is only later recognized as technical debt. The causes can be traced back to inadequacies in transitioning new developers from different backgrounds, recruiting the right people, providing necessary training on new technology or the product environment, and so on.
Inexperienced Teams
Having one or two individuals with little experience or the wrong kind of skills is one type of problem. But with the increasing demand for software professionals, we see cases where organizations need to hire a substantial number of less experienced developers to put together a team, which almost immediately results in the project taking off with technical debt. The Phoebe team unfortunately had to go through this:
At the beginning of this project, there were more than 20 developers, but nearly all of them were entry level (cause). It took us forever to finish even a simple task, and until a couple years ago, it really showed in the code (symptom). Functions were inefficient or needlessly complex, an entire class was copied and pasted from the Internet without regard for how well each part fit into the project, several functions were not actually being used or were unneeded, and duplicate code was found throughout the system (potential technical debt).
The critical point here is to recognize the issues caused by inexperienced teams and provide the right learning environment for them to succeed. In a situation such as Phoebe's, the organization should develop hiring and training strategies and use focused analysis tools to identify, prioritize, and fix the issues brought up in this anecdote. The development artifacts are the copied class, the functions with unneeded complexity, and the unused and duplicate code. To pay the existing debt, the team needs to fix the artifacts and ensure that the costs do not recur.
The knowledge and experience of stakeholders outside the team who have key decision-making power is also critical. For example, the Atlas team endured a period of frustration with the product owner as team members moved their product to a mobile environment:
The cause of the technical debt can be traced to the product owner, who does not understand mobile applications or the systems that mobile applications work with (cause). The product owner also does not understand basic development processes or agile methods. We spend most of our time correcting or teaching the product owner about mobile technologies or development processes in order to do our job.
It is important to recognize that while lack of experience can inject unintentional technical debt into a system, getting caught up in the blame game will take the product or the team nowhere. Technical debt should be traced to the system artifact where it exists. Then the team can determine how to pay existing debt and rearrange responsibilities to ensure that the people with the right skill sets will have the right roles in the future, or needed skill development can be provided. Teams can build competence when they have the resources and opportunities to develop skills, share knowledge, and gain experience as they apply what they have learned in their projects.
Distributed Teams
Coordination issues can create misaligned assumptions about design decisions, which can cause technical debt. Distributed teams face task coordination challenges more often than not. Planning for handoffs should account for potential coordination issues. The Tethys architect offers an example of his project team's interaction with an offshore team:
We learned the hard way that handing development to the offshore team before ironing out all the architectural wrinkles can accumulate significant debt, even when you are taking it on intentionally (cause). We allowed the offshore team to start developing, warning them that the API calls were incomplete in some areas because we needed to understand performance implications better. We assumed that we could coordinate these changes once we decided what to expose on the API. The offshore team had to make certain assumptions on the API to start, which included the incomplete parts, and our teams did not communicate well. Unfortunately, this resulted in redo in multiple areas (technical debt).
The Tethys architect assumed that his team in California could complete the API while the offshore team in Europe started implementation. Because his team arrived at work after the offshore team had gone for the day, it took the California team a few rescheduled meetings to realize that they would have to get to work early to communicate with the offshore team. Although the architect explained that there were missing API calls, the offshore team assumed that if the California team handed over development, the architecture must be good enough. From the perspective of the project lead of the offshore team, he did the right thing. Unfortunately, one of the missing API calls turned out to be key for optimizing performance. Incomplete API calls represented intentional technical debt for the California team. These avoidable misinterpretations between the two distributed teams regarding the status of the API caused the unintended consequence of a performance bottleneck to hit even harder. It took these two teams a while to understand where the issue was located.
Undedicated Teams
In many organizations, developers get pulled in several directions, especially the more experienced ones. This creates not only task switching but also priority shifts. An individual or a team that has competing priorities will focus attention on the most pressing items. In matrixed organizations, project managers should give special attention to setting priorities to avoid losing the attention of teams and individuals. The Atlas, Phoebe, and Tethys projects all suffered from the consequences of undedicated teams, especially as they started to grow. Building effective, focused, dedicated teams is a social and organizational challenge. The downside of not making team building a priority is that when teams are not given enough time, training, autonomy, and resources, they will inject unintentional technical debt as they make design trade-offs to manage priorities.
To Conclude
This chapter describes the causes of technical debt in four major areas: business, change in context, development process, and people and team. Many success stories, as well as failure stories, of technical debt can be traced to one or more causes in these areas. You will find that most of the time, schedule and cost pressure are the contributors that create a domino effect with other causes that pile up as well.Recognizing the causes will help you recognize technical debt, intentional or unintentional.
Knowing the business, understanding the technical underpinnings of the system, avoiding process churn, and building effective teams will help you manage technical debt. Understanding the causes helps you identify the elements of your software development process and organizational realities that create risks for injecting technical debt into your system.
What Can You Do Today?
For major kinds of technical debt, it is important to identify the root cause: schedule pressure, process or lack of process, people availability or turnover, knowledge or lack of knowledge, tool or lack of tool, change of strategy or objectives, and so on.
It is possible to understand and avoid or mitigate the causes of your technical debt immediately, with easy, low-cost actions such as the following:
If you are a software developer, an architect, or a tester who is an active participating member of a development team, communicate the causes you observe with your team. Meanwhile, describe the rework to reduce technical debt that is the consequence of these causes.
If you are a team lead, project manager, or Scrum master, start by asking your team what causes technical debt and what the team can do to avoid these causes.
If you are a software development manager, director, or program manager who oversees multiple projects, create clear communication lines for the business goals and short-term and long-term vision for the product. Give power to your teams and invest in developing their skills. Do not jump to conclusions. Taking a day and a half to conduct a structured root-cause analysis discussion can save you a lot of headaches as your project advances.
When you understand the causes, you can plan specific actions to address them or mitigate their effects.
For Further Reading
In “Technical Debt Quadrant,” Martin Fowler (2009) articulated the difference between deliberate (intentional) and inadvertent (unintentional) technical debt.
Pioneer thinkers in software engineering like Manny Lehman (1980, 1996) and David Parnas (1994) made us aware of the consequences of natural evolution and software aging decades ago. Natural evolution and software aging are two of the reasons all systems have technical debt.
Jim Highsmith (2002)—then of the Cutter Consortium and now with ThoughtWorks—has written extensively about agile project management and the tension between adaptation and anticipation. This tension has an impact on all four areas of technical debt causes that we have discussed: the nature of the business, change in context, development process, and people and team.
George Fairbanks (2010) introduced the idea of “just enough architecting,” which also addresses just enough architecture and design documentation. He focused on the need for effective and sufficient information at the right time rather than architecting and documenting just for checking a box.
Stories from developers and software project managers help us understand how they categorize causes of technical debt. Studies by Lim and colleagues (2012) and Tom and colleagues (2012) provide anecdotes that map to types of causes similar to those we summarize in this chapter.