There's more to Managing Software Debt

If you work with a big system over time, you have to learn how to recognize and deal with technical debt, and how to keep debt under control. Like a married couple with 2 kids in college, paying off a mortgage and a couple of car loans, debt is a fact of life. You have to understand it, come to terms with it.

Debt can be a problem, but it is also a tool. As Steve McConnell explains in Managing Technical Debt there are perfectly valid reasons to take debt on intentionally and strategically. Some things should be done, but they don’t need to be done right now, and as long as you understand the costs and risks involved, you can make a trade off decision. But you will also take on debt unintentionally through honest mistakes (you didn’t or couldn’t know any better) and carelessness (you did know better, or you should have). This is inevitable.

There is a lot to successfully managing technical debt. I have to give props to Chris Sterling for trying to take on this problem on in his book Managing Software Debt.

Sterling looks at different aspects of what he calls software debt:

• Technical Debt: taking short cuts, folding under pressure, deferring work, duplication – the copy-and-paste problem


• Quality Debt: not enough attention to quality, not enough tests, not taking responsibility for fixing bugs


• Configuration Management Debt: mistakes and inefficient practices in version management, build, deployment and release practices


• Design Debt: under-designing and over-designing – expect to get the design right the third time


• Platform Experience Debt: not sharing information, over-specialization

I like the idea of broadening the discussion of debt from code and design considerations to include testing and configuration management, and team considerations as well.

Sterling is an Agile Coach and Trainer, so he predictably looks for answers to managing software debt problems in the context of Agile development. The book is 220 pages long, but only the first 30 pages take on software debt directly; the rest of the book is about how to follow good practices in Agile development, and how this will help you minimize the amount of debt that you take on. It’s more of a primer on Agile development management and design than an analysis of software debt.

If you are building new software and want to take a responsible approach to managing debt for the future, and if you want to know more about how Agile practices and ideas can help you do this, then you may want to read this book. If you want to just get an overview of the book, most of the ideas are introduced here.

I wanted more than a review of good Agile practices. I want more on how to responsibly deal with debt. I want to know more about how to measure and asses the direct and indirect costs of debt, and how to recognize when a team has taken on too much – how to qualify and quantify it. And I want to understand more about how and when to make the case for paying off debt.

Technical debt is about making tradeoffs in cost and risk. I expected more numbers, more analysis on the cost of decisions, the time value of money. And I also expected more war stories, to see more evidence from real life. Everyone is dealing with software debt. There must be more success stories and stories of failures, concrete examples to learn from, more data to chew on and spit out. Instead, there is a couple of short case studies, and a handful of dubious graphs that attempt to quantify the cost of debt, and the return on paying debt back. But on closer review these aren’t graphs, they are pictures: there’s no data to back them up.

In the beginning, Sterling introduces a case study of a company that appears to have run into a wall. They are maintaining a 15-year-old C application, and while they are “doing everything right”, they are facing serious quality problems and can’t meet their delivery commitments. Sterling implies that they have taken on too much technical debt, and now they have to pay the price. But the case isn’t convincing. They are certainly doing something wrong. Yes their code base sounds like it is a mess, the kind of mess you might expect in a big 15-year-old C application, so it’s clear that they have some technical debt problems. But it’s also clear that their planning and technical practices, and their risk management controls aren’t good enough either – or they wouldn’t be in the mess that they are, and they wouldn’t be surprised by it.

There’s not enough to this story to make the case. And the story is left unfinished. The team had a problem and asked for some training. What happened next? Did they find out how much technical debt was holding them back, where the costs were coming from? Did they find a way to pay down their debt and get back on track? What action did they take, what worked, what didn’t? That’s what this book should have been about.

There’s another story later on about a team that had too many open issues (thousands of them), and were now having to spend too much on fixing bugs. Again, not a lot of context, but the lesson was clearer this time –leaving thousands of bugs and problems open for years is going to bite you in the ass eventually. That’s obvious. But there’s not enough here to draw good conclusions from or learn much from.

My other concern is that Sterling’s analysis focuses on a narrow part of the debt problem: preventing yourself from taking on too much unintentional debt by following good practices and disciplined development. doesn’t explore how to make intentional cost/risk trade offs, how to use debt tactically or strategically. It doesn’t help you deal with debt that you have created, or inherited. It doesn’t provide guidance on how to pay debt back, where to start, where you can get the most return, or the fastest return.

There’s more to managing software debt than good clean living, even good clean Agile living. Than doing it right the third time. If you are dealing with technical debt problems, if you have inherited a lot of debt and need to find a way to pay it off, if you want to understand what to do with debt and where to start paying it off, you will get a lot more out of Michael Feathers’ book Working Effectively with Legacy Code.