How to convince a manager to let you pay down technical debt?

Question

While the most recent Coding Horror blog entry is not the first time I had heard of the concept, as I was reading it I couldn't help but apply the it in my mind to my own project.

The code base I'm working on is an ongoing project at about the 3 year mark now, and large portions of the code in the early stages of the project were written by developers who were sub par with little oversight which lead to a lot of code duplication, poor performance, etc. In discussions with management I've tried to make the case that there are several key components that are dying to be refactored and doing so would save a lot of time and headaches in future iterations when adding new features and fixing bugs in these key areas. While they seem to trust me that refactoring these components would be nice, they don't want to give me the leeway to do it. Note that I'm not talking about a rewrite of the entire code base or anything dramatic, just a rewrite of a few core areas that would take on the order of 2-3 weeks.

The questions then, is how to you as a developer sell to your manager that these areas need addressed and make a business case to get the time to address them now, rather than having to just incrementally improve here and there?

Answer 1

The main article from your link has the perfect answer already. This description of technical debt is very good:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

If the project is going to go anywhere the project's manager has to care about it to begin with. If he cares about his project, that description alone should be enough to open his eyes to the idea he probably never thought of. Just help him set up a way to manage noting all the places in your codebase where things need to be improved. Maybe a group or parent ticket in your issue tracking system. That way you can have accountability and a list of what needs to be improved.

Answer 2

The answer, as always, is "Show me the money", e.g - show a business case for your proposed solution. Traditionally this would be done by counting service tasks or help desk tickets related to the substandard code. Your specific case will be difficult because it seems you're speaking of an project not in production.

Just based on what you've written and the fact that your project is still under development, I would caution you to remember the adage "Better is the enemy of done." (I believe it was coined or at least popularized by Michael Lopp.) There might be a better time in the Project life cycle to refactor code.

Answer 3

If management are sympathetic, but they balk at giving you 2-3 weeks to do a complete overhaul, then a compromise would be when you're fixing bugs in those components, write some tests and do some limited refactoring, and over time improve the code.

You could just do it, or you could ask that 10% be added to estimates of bugs/features in those areas to be used for that purpose.

Answer 4

As a manager, I'm open to code refactoring/rewriting for one of three concrete business cases: reducing technical support, adding new functionality, and improving security.

As a developer, I see two additional "close by" cases where I'll refactor/pay down debt. You might find that your manager is open to these or he may just give you "that look" that tells you he doesn't quite buy it.

First, it sometimes makes sense to refactor simply to improve your ability to add new functionality. For example, if you can see business on the horizon that will require your system to be more flexible and adaptable, then you may need to rethink some of your original architecture's commitments. This is a great time to pay down debt.

Second, when new code is being written that is related to a component that already exists then it makes sense to pay down some debt. For example, if you were adding a new class that is logically a brother class of an existing one, then refactoring out common code into a parent class makes sense. As you do this, you have a great opportunity to pay down debt as well.