Although technical debt has existed in software systems ever since there was software, the term “technical debt” and the metaphor comparing it to financial debt are more recent. This book is intended for practitioners. Its purpose is to provide them with practical advice on recognizing, analyzing, and actively managing technical debt in real-world development projects.

The book consists of 13 chapters divided into four parts. The first chapter of Part 1’s three chapters introduces the technical debt metaphor and situations where technical debt exists, and gives the authors’ definition:

[T]echnical debt consists of design or implementation constructs that are expedient in the short term but set up a technical context that can make a future change more costly or impossible.

The first chapter also lists nine software engineering principles for technical debt management, which are expanded on and referenced throughout the rest of the book. These are things like, “all systems have technical debt,” “all code matters,” and “technical debt has no absolute measure.”

Chapter 2 expands on the forms of technical debt in code, architecture, and infrastructure. The third chapter introduces three fictional case studies, which are used as examples throughout the book. Three mythical companies are used: a small startup with a single e-commerce product; a medium-sized agile company in health information with an established product; and a large, global multi-business corporation supporting a 15-year-old safety-critical embedded avionics product line. It uses the differences in the cases to highlight the importance of context in discussing technical debt.

The second part contains four chapters focusing on technical debt itself. A chapter on recognizing technical debt describes the symptoms and consequences of technical debt and introduces the notions of a technical debt item and the technical debt description for recording technical debt items. The following three chapters discuss, in turn, each of the three sources of technical debt: source code, architecture (one of the nine technical debt principles is “architectural technical debt has the highest cost of ownership”), and the environment (or production).

Part 3 emphasizes how to decide which technical debt to fix. One chapter describes how to figure the cost of technical debt items so the most critical items can be addressed first. The second chapter discusses how to service technical debt so the cost does not become too high.

The fourth and final part is devoted to managing technical debt, both strategically and tactically. The first of its four chapters discusses causes of technical debt. The second gives a quick method of running a credit check to determine any existing levels of technical debt. The third chapter describes ways of avoiding unintentional technical debt. The final chapter is on living with technical debt.

Each chapter ends with a further reading section that provides annotated recommendations pertinent to the chapter. These roughly 100 items are collected in a bibliography at the end of the book. A short 26-entry glossary and a 21-page index are also included.

This book is well written and organized, and does what it sets out to do. I can recommend it to anyone looking for practical advice on technical debt.

More reviews about this item: Amazon