Review By: David Fern
06/30/2011

Are you accumulating software debt? Chris Sterling's "Managing Software Debt: Building for Inevitable Change" will make you rethink the way you develop software.

This book is a quick and easy read, full of real-life code examples, stories, and even a few short case studies. It describes the five types of software debt (technical, quality, configuration management, design, and platform experience), how to identify these debt sources, and, most importantly, how to prevent or minimize them from entering your software. Many of the techniques for reducing software debt are simply the application of sound software development practices.

Although these techniques may be used in any development methodology, the author touts the benefits of agile. He gives examples of how using agile reduces software debt and expounds on its benefits over the "big design up front" methodologies. Don't worry if you are unfamiliar with agile, because the author includes a "What is Agile?" appendix explaining Extreme Programming (XP) and Scrum at a very high level.

Some of the author's quotes really hit home and stuck with me long after reading the book. I liked "We will not get it right the first time, well get it right the third time" and "People are NOT resources!" He also asks for your definition of "done." Does your organization have a common understanding of the term? I often hear people say that they are done, but they do not hand over the finished product because they are not "done done."

As a QA/QC professional I really like that the author includes quality and testing throughout the chapters, including discussions on automated testing concepts and examples of test frameworks and techniques that you can immediately start using.

I did have two minor items that I would change. First, I could not find a definition of "software debt" anywhere in the book. I understand the concept through the many explanations of how it accumulates and of the different types of software debt, but I would like to see a definition. Secondly, I thoroughly enjoyed the specific software debt chapters in the book, but chapters nine and ten, “Communications Architectures” and "Technology Evaluation Styles," did not really seem to fit in and appeared to be more about architecture best practices.

The real takeaway is, as the author puts it, that "software should be designed and constructed for change." Software will continue to be maintained and enhanced, but if you do not start with sound development principles, it will quickly collapse under the software debt that starts accumulating when the project starts. I recommend this book to anyone involved in software development, since software debt is everywhere, continually accrues, and must be kept in check, requiring the work and cooperation of everyone throughout all phases of the software development lifecycle.