In today’s post, I review Managing Technical Debt: Reducing Friction in Software Development, by Phillippe Kruchten, Robert Nord, and Ipek Ozkaya.
NOTE: At erikscode.space, book reviews do not contain affiliate links or paid advertisements. They are not written at the request of one of the authors or publishers, paid or otherwise. There are no incentives that would sway this review in a positive or negative direction. This review is based purely on the article's author's personal opinion.
Background
The Concept of Technical Debt
Technical debt is a concept that many–if not most–software professionals are familiar with. In this book specifically, technical debt is defined as:
design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible
Managing Technical Debt: Reducing Friction in Software Development. Kruchten P., Nord R., Ozkaya I.
This is a concise and approachable definition of the concept upon which most software professionals would agree. Technical debt pervades software development, it is simply a fact of life for anyone involved in building software. However, despite the foreboding “debt” in its name, it’s not something we universally avoid and reject. Technical debt is something we manage and use intelligently to build the best software with the resources we have.
The first written reference to technical debt as an analogy that I’m aware of is in Ward Cunningham’s paper The WyCash Portfolio Management System. Another foundational source is Frederick P. Brooks’ paper, No Silver Bullet — Essence and Accident in Software Engineering, which conceptualizes the challenges inherent in software development.
The Authors
Phillipe Kruchten is a professional software engineer with a few decades of experience. He is also a professor emeritus at The University of British Columbia. Kruchten has published several peer-reviewed papers and is an editor of both Journal of Systems and Software, and IEEE Software. Another notable accolade is that Kruchten was one of the main developers of the Rational Unified Process (RUP).
Robert Nord is a principal member of technical staff at the Software Engineering Institute (SEI). He is an experienced researcher and prolific author of peer-reviewed publications.
Ipek Ozkaya is a technical director at the SEI and is the editor-in-chief of IEEE Software. She has a long history of impactful involvement in the IEEE and has also authored several peer-reviewed papers. Like Nord, her experience appears to be primarily academic and research-based.
Overview
Managing Technical Debt, as its name implies, is a book about the concept of technical debt in software development. The authors spend this short book talking about how to manage technical debt by presenting three companies:
derived … from actual companies that we authors have interacted with, but we abstracted many characteristics and details for confidentiality reasons, and in some cases we combined characteristics from two similar organizations into a single example.
The book is thirteen chapters long and broken into four parts:
- Exploring the Technical Debt Landscape
- Analyzing Technical Debt
- Deciding What Technical Debt to Fix
- Managing Technical Debt Tactically and Strategically
Review: Mostly Good!
Overall, the book is well-written and contains a lot of good information for software professionals of all disciplines. I believe readers should have at least a few years of experience in software in order to fully absorb the value of this book as one needs to have experience working inside of a team and company for some time to understand the true nature of technical debt.
General Notes
Typically, I am wary of software engineering books written by career professors and researchers. Decades of research experience are certainly nothing to scoff at, but I believe industry experience is a prerequisite for having valuable information to share with software engineers. Conducting research on software development process phenomena requires being on the outside looking in. Because of this, it’s easy to make principled statements that are naïve to the subtle effects of things like business contexts, office politics, or team dynamics.
Having said that, this book remains relevant to industry practitioners throughout. There is one important thing to note if you are an experienced developer about to read this book for the first time. This book isn’t about preventing technical debt, it’s about managing it once you know it’s there. Dr. Ozkaya made this distinction in episode 481 of IEEE Software Engineering Radio. Once I understood this, I reread some of the passages I highlighted as “naïve to industry practices” and appreciated them more.
One example of such a passage was in chapter 5: Technical Debt and the Source Code. The authors introduce a company whose business goal is to create evolvable software but is constantly hamstrung by poor quality in the source code. The listed cause of this is “Inexperienced team members create conditions for the occurrence of technical debt.”
To me, the obvious way to prevent such a problem is improving code review processes. “if inexperienced team members are merging bad code into main, the review process is obviously broken” I thought to myself. However, the goal of this chapter is not to talk about preventing this from happening, it’s about managing the debt that already exists. The authors do a great job of sticking to this goal by suggesting ways to measure and track this problem and its symptoms in support of the “create an easy-to-evolve product” business goal.
Not as Helpful for SaaS Developers
One weakness I did find with the book is that, as a developer in a medium sized SaaS company, I thought a lot of the content was tailored to developers in big companies, particularly where the software was not a product being sold.
There are a lot of suggestions on analyzing and communicating a project’s technical debt and quantifying its impacts. However, this documentation effort isn’t the kind of thing small to medium sized companies typically make time for. In my experience, it’s enough for a senior engineer to say something like “we need to take some time to clean some of this up” to get management sign off on technical debt cleanup efforts.
Working in SaaS, there is lots of technical debt to contend with, and many parts of this book are helpful. However, if you are like me in that the software you work on is actually being sold to customers, you can probably get a way with skipping chapters 8, 9, and 13 and you can just skim over parts of the book in which you see this figure:
Conclusion
Pros: Excellent examples, thoughtful approaches to a tricky problem, superb sources
Cons: Seemingly tailored to a large company context. May be a bit too “academic” at times for purely “industry” people.
Overall: Quick and useful read for mid-level software professionals and managers. Possibly a good starting point for software engineering researchers looking to conduct research in the areas of technical debt, development methodologies, or the intersections of software development and project management.
Check out my post 5 Great Programming Books Rarely Mentioned in “Great Programming Books” Articles