Managing Software Debt

Technical debt has become a trendy term for an issue that exists since the beginning of software development projects. It is what happens when you neglect, consciously or not, the long-term quality of your software to achieve other usually short term benefits. After defining the concept of software debt, Chris Sterling explores the topic of managing software debt in all software development activities. Three chapters are dedicated to the topic of design and architecture, discussing how they should fit in Agile approaches.

As its title suggests, this book goes even further than the concept of technical debt as it try to cover all dimensions of software development debt. My favorite chapter comes at the end where the notion of experience debt is explored. I have witnessed many projects where the technical or product knowledge was concentrated on fewer and fewer people, due to change in project team composition, effectively making them the bottlenecks where all application evolutions had to be processed. We sometimes create more debt in the heads than in the code.

The book is well written and easy to read. Every chapter begins with a mindmap of the topic that will be explored, thus giving a big picture of its content. The material mixes high level definitions with practical examples and real life stories. A summary is proposed at the end of each chapter

At every stage of the software development life cycle, we make decisions that have long term consequences. This book provides meaningful insights on how to prevent creating too much debt and how to reduce the existing burden. I will recommend it to everybody who is concerned with software quality with a longer view than the end of the next iteration.

Reference: ” Managing Software Debt – Building for Inevitable Change “, of Chris Sterling, Addison-Wesley, 228 pages, ISBN 978-0-321-55413-0

Get more details on this book or buy it on
Get more details on this book or buy it on


“Software debt creeps into systems slowly, allowing both the business and software delivery teams to maintain the illusion of rapid delivery far longer than they should. At some point small form of decay in software become large enough to affect delivery to a point where working harder and longer doesn’t result in successful outcomes.”

“Agile teams should not forget that software development involves more than code and test. The act of releasing software is essential and teams can help to make the act almost a non-event.”