Kruchten P., Managing Technical Debt (2019)
The book presents a concise and structured look at what the technical debt is, where it comes from and how to treat it in short- and long-term perspective.
The book is somewhat a middle ground between business and engineering perspectives, gravitating towards managerial aspects of technical debt.
It suggests a number of useful techniques for managing the debt. Meanwhile, some of the techniques look inapplicable trying to solve the engineering issues using managerial approaches.
Summary
[INTERESTING] Read Technical Debt in the Eye of the Beholder explaining the phenomenon of inexistent technical debt and Sloppy Code As a Silent Business Killer touching on primary source of technical debt and its consequences for a starter.
The technical debt section of my review of McConnell's More Effective Agile book comprises very practical and concise classification of 5 debt types and how to treat them.
My writings A Business That Doesn’t Waste and Producing Top-Quality Code Is Fast can be also of interest in the context.
The book is clearly structured into 4 parts, presenting what the technical debt is ("Part I: Exploring the Technical Debt Landscape" and "Part II: Analyzing Technical Debt") and what to do with it ("Part III: Deciding What Technical Debt to Fix" and "Part IV: Managing Technical Debt Tactically and Strategically").
Most of the chapters contain the section "What Can You Do Today?" that lists actions supporting practical implementation of the chapter content.
The other standard section of nearly each chapter is "For Further Reading". It briefly reviews the sources where the content of the chapter originated from.
Both sections are of great use, to my taste.
What Technical Debt Is
[Kruchten P.] The term technical debt is not new. Ward Cunningham introduced it in 1992 to communicate the delicate balance between speed and rework in pursuit of delivering functioning quality software. (p. 3)
[Kruchten P.] You can think of technical debt as an analogy with friction in mechanical devices; the more friction a device experiences due to wear and tear, lack of lubrication, or bad design, the harder it is to move the device, and the more energy you have to apply to get the original effect. (p. 4)
Technical debt in software systems refers to short-term design or implementation compromises that increase future costs or hinder changes. It acts as a contingent liability, mainly affecting internal qualities like maintainability and evolvability.
Indebted Artifacts and Cost Model
(ch. 2)
The software artifacts that may incur the debt are code, architecture, production infrastructure. At the same time defects, low external quality, security, unimplemented requirements are often consequences of technical debt but not the technical debt in themselves.
The technical debt is invisible to non-technical stakeholders but impacts them financially: inflexible product causing marketability weaker than competition, multiple defects in production sometimes costing orders of magnitude of the fixing costs etc 1.
[VS] The reasons of appearing technical debt in code do not include the biggest issues in software - inadequate requirements specification and the absent, unconscious middle-level (code) design decisions.
The technical debt cost model presented in "Chapter 2: What Is Technical Debt?" (p. 24) is good for illustration purposes but lacks the variety and size of consequences. Follow the links I put above for a broader considerations.
The examples presented in-home MEAN stack application as inherently indebted vs "better" commercial middleware also look a little off the practice, maybe for the reason the book tries to hit the middle ground between business and technology audiences.
Analyzing the Debt
Debt Consequences and Registration
Here is the summary on consequences of the technical debt visible to non-technical stakeholders.
| Consequence | Attributes |
|---|---|
| System Manifestations |
|
| External Manifestations |
|
| Higher Remediation Cost | By the time symptoms are visible, technical debt is far more more expensive to fix (see 1:10:100 rule) |
The book suggests registering the debt at its discovery time using the specific template with the usage example (p. 57-59). This is the great idea if the engineering team has a competency to anticipate and recognize the debt and its consequence, and assign the remediation. However, the book itself is not enough to teach this competency.
Another great advice is to understand the business context where technical debt is assessed. The book suggests the framework for this (p. 59). In practice, this assumes engineering team has the cross-functional competency in business that is rare.
Despite these issues technical debt registration, event in its simples form, is a beneficial endeavor in many aspects (p. 63). A journey of a thousand miles begins with a single step.
Recognize It
In Source Code
(p. 65)
The book suggest to apply the automated code analysis tools 2 that is the great first step of discovering basic technical debt.
[VS] This is much better than nothing, however the tools are only helpful for standard code smells, security issues, code complexity etc. and useless for subject domain modeling drawbacks and architecture or application design.
Besides, the tools by themselves are not enough to enforce paying the debt. A team must possess the competent managerial will and the relevant engineering competence.
To support managerial decisions, the book introduces the code technical debt consequences metrics (defects and security issues trends, fixing costs, rigidity to changes, slower development) that, being reported, at least quantifies the trends.
In Architecture
(p. 83)
The book suggests recognizing the architectural debts by asking engineering people as they are expected to know where it resides. That depends completely on the engineering competency levels. This is not discoverable with code analysis tools mentioned above. It may accumulate slowly similar to the source code debt, or surface abruptly.
[VS] The book suggests the managerial process of asking engineering team to discover architectural debt (p. 87).
This is difficult to apply by non-engineering people, though. If the engineering team is competent enough, they already manage all intentional architectural debt and communicate it to managers. Or they just do not allow the unintentional debt to be introduced.
If they are not, then managers have little practical leverage to uncover or mitigate it except they invite a competent consultant, who would use different approaches for discovering technical debt.
In Production
(p. 104)
Technical debt in production affects release processes code—build, test, deployment, and release. It involves infrastructure-as-code (scripts, automation), which can introduce debt due to tool complexity, poor readability, testing challenges, dependencies or environments mismatch.
The debt manifests in build, /integration issues (flawed scripts, missing infrastructure), testing gaps (outdated tests, environment misalignment), and infrastructure weaknesses (manual tasks, poor observability).
Recognizing production debt is simpler due to simpler code in release pipelines and more surfaced signals (slow builds, dropping velocity signal, immediate production errors coming from dependencies mismatch).
The production debt is usually is of much less problem as the release pipelines change much more seldom than application code.
Fixing Technical Debt
(p. 115)
The "Part III: Deciding What Technical Debt to Fix" suggests the way of costing technical debt.
[VS] In my view, the part misses the point of "1:10:100 rule" - a rule of thumb as well as the fact the business consequences of any technical debt may come orders of magnitude larger than what is described in the chapter.
It also tries to derive the cost/benefit equation with no quantifiable values and on minor items as well as qualitatively assess the opportunity cost. While these approaches have the theoretical value, they are difficult to apply due to vague quantification and cross-functional (business-engineering) nature.
Read and decide for yourself if the chapter adds the practical value or not.
Tactics and Strategy in Debt Management
(p. 149)
The "Part IV: Managing Technical Debt Tactically and Strategically" describes the causes of technical debt (p. 151), tries to present the systematic managerial approach for identifying potential risks of technical debt (p. 167) 3, tells about how to avoid unintentional debt (p. 179) and reviews the tools to manage the debt (p. 199).
Footnotes
-
On discussion of defects refer to "the later you discover a requirements mistake, the more it costs to fix" observation and "1:10:100 rule" in my review of" Writing Effective Use Cases" book. ↩
-
SonarQube is an easy-to-integrate solution that can work locally in your team IDE and in CI pipelines. ↩
-
Which, from my standpoint, is hardly useful due to the fact any technical debt is easily seen to a competent engineer at its very roots but it is impossible to discover robustly and timely by managerial techniques.
Just for info, 5 seconds look at project folder structure and at any of its custom modules source code is enough to tell if a software is written by competent engineer, or if it is a ball of mud (1, 2, 3, 4).
In this regard, the competent engineers are similar to people with musical ear. They see the "false notes" in code at the first sight, while other people with no such capacity do not discern that. ↩