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 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. Coverage includes Using this book’s techniques, senior software leadership can deliver more business value; managers can organize and support development teams more effectively; and teams and team members can improve their performance throughout the development lifecycle.
Surprisingly well written - for a project management book. Like most self-help books the title says it all. The debt metaphor is useful because everyone has experience with debt and already knows how to manage it. Avoid getting into debt; once you're in debt, acknowledge it and devise a plan to get out.
I didn't really know what to expect from "Managing Software Debt." It was the first time I've seen the phrase software debt in a title so I was intrigued. The book does not assume you are a developer or a manager and makes it readable for both.
The descriptions of how debt creeps into the process was excellent.
My five favorite parts were: "abuse stories" (anti-use cases) the last chapter - people aren't resources and why this matters along with styles of teams the word "done" repeatedly being in quotes and an exercise on how to create a definition the cost of someone else paying the cost of your poor decisions why silos create debt
I made lots of highlights and was engaged as I read. I didn't make notes in the book because some would be less than favorable to someone who could pick it up. It definitely hit home though.
I would have liked some more tips on how to deal with debt and how to prevent it. The book was certainly thought provoking and raised my awareness of debt in day to day work.
--- Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
My main issue with this book is many of the theories presented in this book are that - just theories - but the author presents them as fact. It is also disturbing to see so many links to wikis and discussion boards as documented references. And please do not get me started on the completely made up graphs!
The reason I give this 3 stars though, is that it is one of the first books to fully capture the root causes of technical debt and suggest system-wide solutions to these causes. I'm reading this for a work book group and it has been invaluable in starting discussions on how to get technical debt stories into our product backlogs to bring visibility to known technical debt.
Sterling does a good job covering the bases - I particularly enjoyed his treatment on Technical Debt - but does not offer much further by way of execution strategies. I found Continuous Delivery to be a much fuller treatment of the means by which a team might overcome debt. That said, I think this book is a good read for those interested in cataloging the subject of software debt.
Good book to gain an understanding of the concepts of DEBT in software design and development activity. Chris did a great job of covering the many angles of this problem and provides many suggestions for getting a handle on managing your technical debt.