This chapter is from the book
This chapter is from the book
This chapter is from the book
Navigating the Concepts of the Book
The goal for this book is to provide practical information that will jump-start your ability to manage technical debt. The chapters that follow inform the basic steps of technical debt management: become aware of the concept, assess the software development state for potential causes of technical debt, build a registry of technical debt, decide what to fix (and what not to fix), and take action during release planning. The steps draw on the seven interrelated concepts shown in Figure 1.1 that are the basis for managing technical debt.
){kind=link}
Figure 1.1 Major concepts of technical debt
This book organizes the chapters into four parts.
In Part I, “Exploring the Technical Debt Landscape”—Chapters 1, “Friction in Software Development,” 2, “What Is Technical Debt?,” and 3, “Moons of Saturn—The Crucial Role of Context”—we define technical debt and explain what is not technical debt. We introduce a conceptual model of technical debt and definitions and principles that we use throughout the book. We want to make technical debt an objective, tangible thing that can be described, inventoried, classified, and measured. To do this, we introduce the concept of the technical debt item—a single element of technical debt—something that can be clearly identified in the code or in some of the accompanying development artifacts, such as a design document, build script, test suite, user’s guide, and so on. To keep with the financial metaphor, the cost impact of a technical debt item is composed of principal and interest. The principal is the cost savings gained by taking some initial expedient approach or shortcut in development—or what it would cost now to develop a different or better solution. The interest is the cost that adds up as time passes. There is recurring interest: additional cost incurred by the project in the presence of technical debt due to reduced productivity, induced defects, loss of quality, and problems with maintainability. And there is accruing interest: the additional cost of developing new software depending on not-quite-right code; evolvability is affected. These technical debt items are part of a technical debt timeline, during which they appear, get processed, and maybe disappear.
In Part II, “Analyzing Technical Debt”—Chapters 4, “Recognizing Technical Debt,” 5, “Technical Debt and the Source Code,” 6, “Technical Debt and Architecture,” and 7, “Technical Debt and Production”—we cover how to associate with a technical debt item some useful information that will help you reason about it, assess it, and make decisions. You will learn how to trace an item to its causes and its consequences. The causes of a technical debt item are the processes, decisions, action, lack of action, or events that trigger the existence of a technical debt item. The consequences of technical debt items are many: They affect the value of the system and the cost (past, present, and future), directly or through schedule delays or future loss of quality. These causes and consequences are not likely to be in the code; they surface in the processes and the environment of the project—for example, in the sales or the cost of support. Then we cover how to recognize technical debt and how technical debt manifests itself in source code, in the overall architecture of the system, and in the production infrastructure and delivery process. As you study technical debt more deeply, you’ll notice that it takes different forms, and your map of the technical debt territory will expand to include this variety in the technical debt landscape.
In Part III, “Deciding What Technical Debt to Fix”—Chapters 8, “Costing the Technical Debt,” and 9, “Servicing the Technical Debt”—we cover how to estimate the cost of technical debt items and decide what to fix. Decision making about the evolution of the system in most cases is driven by economic considerations, such as return on investment (for example, how much should you invest in the effort of software development in a given direction, and for what benefits?). For the technical debt items, we will consider principal and interest and associate elements of cost to reveal information about the resources to spend on remediation and the resulting cost savings of reducing recurring interest. We then revisit the technical debt items in the registry collectively and use information about the technical debt timeline to help determine which technical debt items should be paid off or serviced in some other way to ease the burden of technical debt: eliminate it, reduce it, mitigate it, or avoid it. We show how to make these decisions about technical debt reduction in the context of a business case that considers risk liability and opportunity cost.
In Part IV, “Managing Technical Debt Tactically and Strategically”—Chapters 10, “What Causes Technical Debt?,” 11, “Technical Debt Credit Check,” 12, “Avoiding Unintentional Debt,” and 13, “Living with Your Technical Debt”—we provide guidance on how to manage technical debt. A key aspect of a successful technical debt management strategy is to recognize the causes in order to prevent future occurrences of technical debt items. Causes can be many, and they can be related to the business, the development process, how the team is organized, or the context of the project, to list a few. We present the Technical Debt Credit Check, which will help identify root causes of technical debt that show the need for software engineering practices that any team should incorporate into its software development activities to minimize the introduction of unintentional technical debt. The principles and practices you will have learned along the way make up a technical debt toolbox to assist you in managing technical debt.
At the end of each chapter, we recommend activities that you can do today and further reading related to the concepts, techniques, and ideas we discuss.