Book Review: Managing Software Debt by Chris Sterling

When I read Earl Everett’s foreword to Managing Software Debt: Building for Inevitable Change, I knew I wanted to keep reading. He points out that “system architecture is a human activity”, and that Agile recognizes the humanness of systems development. That’s my experience, and this book affirmed that delivering valuable software frequently and consistently over the long term requires having the right people and letting them do their best work. In Chapter 8, the author references Gerald Weinberg’s “Second Law of Consulting”: “No matter what the problem is, it’s always a people problem”. When this sentiment runs through a book, it resonates with me. Also – I can’t resist a book in which each chapter starts with a mind map! (Hmmm, where have I seen that before? ;-> )

My copy (the old-fashioned print kind) bristles with Post-It tabs marking so many terrific observations. The author advocates a whole team approach to development, where testers, programmers and other roles work together. One statement I especially like: “Everyone on the team should be able to execute any and all automated and manual test cases.” (p. 59) Amen!

I appreciate the graphics illustrating how software debt impacts applications over time, such as the downside of “like-to-like” migrations where organizations think they can simply do a new project to replace their system with a better solution. The book makes excellent use of graphs, illustrations, whiteboard drawings, and code examples to clarify various techniques that reduce debt and promote quality.

The first step in paying back technical debt is to acknowledge that it exists. The author points out that “No matter what, the cost of addressing technical debt increases with time”. In my experience, teams often say that their management won’t approve their working on the technical debt, when in fact, if the business executives such as the CFO understood the cost, they’d prioritize it over new features. In this book, you will learn how to quantify the cost of the debt and the return on paying it back, and how to help your customers understand it. As the author notes, the customer expects the team to know how best to develop the software they need. Graphs illustrate how much the cost of technical debt increase over time. We’d be irresponsible if we failed to educate our customers about this.

The book presents different techniques for cleaning up software debt, supported with code examples where appropriate. More importantly in my view, the reader will learn approaches that enable teams to sustain internal quality, including sustainable pace, collaboration, refactoring, small batches of work, and more. It goes on to explain these approaches in detail, again with examples and illustrations to make them clear.

The chapter on quality debt looks at reasons why teams don’t automate regression tests, both functional and extra-functional, and shows how this leads to ever-lengthening regression test execution time. The author points out the drawbacks of having multiple queues of work, including a defect tracking system, and gives several alternatives for overcoming these issues. I like the emphasis on correct test design when using ATDD to address quality debt.

The only issue I had with the book was minor. I really liked the section on tracking issues collaboratively, but it seemed out of place in the release management chapter.

One great technique I learned from the book that was new to me is “abuse stories”. Your customers might not prioritize a story that says “Implement security for payment information”, but this story might get their attention: “As a malicious hacker, I want to steal credit card information so I can make fraudulent charges”. I’d love to participate in an abuse story writing session now that I know how!

In my experience, an organization’s culture is more important than any technique or practice. The author points out that teams need to learn the skills and knowledge to address evolving product requirements, and they need time to do this. He then explains various ways to create knowledge and apply it to the product, and how to budget for this. Now, don’t roll your eyes and say “our customers will never allow us to take this time” if you haven’t explained the technical risks of not doing a technology evaluation. This book will help you work with the customer to identify technical unknowns while making progress toward providing new features.

The book addresses the interesting issue of extreme specialization. The author suggests that we should give projects to cross-functional teams instead of creating teams to work on projects, which enhances learning and avoids knowledge silos. I was especially pleased to read the section in Chapter 11 on personal development, with examples of how various teams make time for individual and team learning.

I wished the book had more of a “big finish”, but I like the concluding paragraph, which starts: “Investing in people is probably the most effective way to create sustainable software”. (p. 220). That’s congruent with my own experience. Many of the topics in this book have been covered in other books, but here you will see them in a new perspective. We want to deliver business value frequently, year after year, while working at a sustainable pace and enjoying ourselves. If that is not happening where you work, this book will help you reverse the trend.