Managing Software Debt: Building for Inevitable Change
Shipping imperfect software is like going into debt. When you incur debt, the illusion of doing things faster can lead to exponential growth in the cost of maintaining software. Software debt takes five major forms: technical, quality, configuration management, design, and platform experience. In today’s rush to market, software debt is inevitable. And that’s okay—if you're careful about the debt you incur, and if you quickly pay it back.
In Managing Software Debt, leading Agile expert Chris Sterling shows how understanding software debt can help you move products to market faster, with a realistic plan for refactoring them based on experience.
Writing for all Agile software professionals, Sterling explains why you're going into software debt whether you know it or not—and why the interest on that debt can bring projects to a standstill. Next, he thoroughly explains each form of software debt, showing how to plan for it intelligently and repay it successfully.
You'll learn why accepting software debt is not the same as deliberate sloppiness, and you'll learn how to use the software debt concept to systematically improve architectural agility.
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.