Paying Down Code Debt

We have huge code debt. We want to pay it down. But we just can’t afford to this week (or last, or the one before that). How can we afford to pay down our debt?

OK, it’s not a direct quote. But I’ve heard something close to that often enough that random word ordering may have actually created exactly that statement at some point.

Here is a set of techniques that I’ve used in the past to start paying down debt in situations where we were all sure we’d never be able to afford to.

What is Technical Debt?

First, a definition for clarity.

Technical debt is friction. It is anything that inhibits your ability to delight customers, typically by decreasing productivity, increasing variance, lengthening feedback cycles, or decreasing your ability to adapt to changing circumstances.

Or, to put it more succinctly:

Technical debt is anything that sucks.

Getting All Formal

First, I recommend that you create a formal plan to pay off your debt. Paying down the debt requires consistent, concerted effort by everyone in the team for a long period of time. It doesn’t happen without full buy-in. Getting that buy-in requires that people know what they’re buying.

Making a plan doesn’t mean spending months on analysis to find every problem in your system. Your devs already know the problems: any code they either hate or fear is a problem. You don’t have to spend time prioritizing your problems: the most important ones are a) whatever your devs fear most (fear is the emotion of your subconscious risk analyzer) and b) whatever impacts the code that you are changing.

But the plan does need to cover the following:

  • Agree to stop digging. Stop introducing new debt.
  • Agree how much you want to spend.
  • Agree that features will be coming out slower for a while.
  • Agree that the devs get to choose what to fix—not management, scrum masters, or the product owners. The devs know where the important debts are; the other people don’t.
  • Agree how you will recognize success.
  • Agree that you will celebrate success.

And shop the plan around. Make sure that everyone agrees: leads, managers, product owners, devs, testers, and any other stakeholders your team may have. Make sure that there is real support for the plan, not just grudging buy-in.

So what form should the plan take? What is in it? I like:

The Investment Portfolio

What: Agreement on budget to spend in each of 3 categories: short-term gains (take advantage of opportunities & fix bugs that annoy customers), long-term gains (anything of strategic value), and sharpening the saw (anything that makes devs more productive or reduces variance).

The ratios are set by high-level management (as high as you can get). The team is expected, each week, to actually come within 5% of each budget number. Falling out of budget in any category—whether high or low—means the sprint failed.

Why: When you ask management for these ratios, they give consistent results. They have the perspective to care about both the long- and short-term health of the company. So they almost always answer between 30% and 50% for sharpening the saw (based on current debt), then split the remaining budget 50/50 between short- and long-term gains.

This is a healthy investment profile. It is also rarely the investment profile that emerges from the specific decisions made by a product owner or product council. By getting this number from above, we can both get a healthier number and later lean on that executive support to allow us to stick to our guns.

Next up: choose how to recognize and celebrate success.

Trust the Experts

There are all sorts of fancy metrics and code analysis tools that will claim to find code debt for you. But all of them, necessarily, miss some things and over-report others. There is one tool that stands out as far more accurate than any other: the subconscious minds of the people who work with the code day after day.

Our subconscious minds are awesome pattern-matching engines. They incorporate tons of data that we don’t even notice. They associate to all sorts of past experiences. They make decisions before our conscious minds have a chance to rationalize (make stuff up). In case after case, they are simply the best tools we have to understand complicated or complex systems.

The only problem is that our subconscious communicates with us emotionally. And we are trained to ignore & suppress our emotions (this is especially true of Americans, the middle-class, and men).

The subconscious sends you an emotion when two things are true:

  • Something important happened.
  • The subconscious knows why it was important.

4 key emotions tell us very useful information:

  • Sad: something important to me just got destroyed.
  • Mad: something just trashed something important to me (wasted my time, rejected my thinking out-of-hand, etc).
  • Glad: something important to me just came into being.
  • Afraid: there is a risk to something important to me.

So, you want to know what your code debt profile is like? Ask the devs how they feel about things.

  • Things they fear are probably the big technical risks to your project.
  • A tool or improvement that makes them happy probably helped them do something that matters.
  • Things that make them sad (dejected, hopeless) probably mean that you just lost a key success factor.
  • And things that piss them off are probably fantastic wastes of their time.

The other key thing to remember about devs is that most of us have a builder personality. This means that we get happy when we build something that makes a difference in someone’s life. The best reward to a builder is an honest thank-you from a single person that states how their life is better. And the best way to annoy a build is to get in the way of his ability to build stuff.

So builder devs have emotional reactions that align very well with the goal of reducing technical debt. Let’s use that. How do we recognize and reward success?

Let’s Get Emotional

What: Ask the builders who are using the code every day how they feel about the code, the process, the meetings, the tools, and basically everything else. They will like the things that contribute to their ability to serve customers. They will be angry at things that slow them down, and afraid of things that potentially might inhibit their ability to build.

Reward successes with honest thank-yous. Demo the “sharpening the saw” work in your iteration demo. Show how it makes someone’s (probably a developer or someone in tech support) life better. Show how that will (or did) let them build more and better stuff for customers. If it makes your life easier, thank them. If it doesn’t, then don’t: every thank-you must be sincere. But even then, recognize what happened and how it will make it easier to make customers happy.

Why: See above. I had to state it first because otherwise too many of my readers would have rejected the technique without understanding why it works.

The Rest is Talking

All the other aspects of the plan are just getting everyone to agree. Find all the stakeholders. Identify their concerns. Help them tweak the plan to satisfy their concerns (for example, add a quarterly review of the investment profile). And then get agreement.

There really isn’t much to the plan; we just need enough to get everyone aware of the problem and on the same page about solving it.

You don’t have to use the approaches that I outlined above; these are just approaches that I’ve found successful in the past. Make up whatever you want.

Just keep it simple. If the entire plan doesn’t fit on one side of a sheet of paper, then it is probably too complicated to work. Delete stuff.

Now Do It

I’ve shown one simple way to get a plan. A plan won’t be enough to solve the problem; you still won’t actually be making investments into paying down technical debt. But a plan with agreement will make it possible. It will help you set up a structure that reinforces paying down debt, rather than reinforcing taking out more loans.

So start working on your plan & stakeholder buy-in, and I’ll start writing the second blog post in this series: a dozen or so techniques you can use to make sure that you actually spend your various budgets each week, and that you get something for your expenditures.

Actually, I’ve already written that blog post as an email. So start getting agreement now and you’ll be able to take advantage of next week’s post about operationalizing your plan.

8 thoughts on “Paying Down Code Debt”

  1. I'm having a bit of trouble understanding the budgeting. You said that one example plan might be 50% sharpening the saw, 25% short-term wins, 25% long-term strategic value. Is this "the budget" as in over all budget for the project? Or is this the code debt payoff budget? If it's the former then I have a hard time believing that management will suggest spending 50% of the budget improving dev environments etc, with only 50% of time going to bug fixes and new feature development. If it's the former then…well, I don't know how much of the actual budget it is!

    btw I will not be surprised at all if you say, "you may have a hard time believing it but it's true."

    I can't really critique this either way yet because I don't think I understand it yet. Can you clarify a bit about what you mean by the budget and how you're allocating the time? I would think that only the project's overall budget makes sense, and that you wouldn't have a code debt sub-budget. But if it is the project's overall budget, I'm having trouble with those numbers you quoted.

    1. Yes, this is the total budget allocation.

      50% is the high end for saw sharpening. I have only seen it in companies where the exec was disappointed with current rate of development. In those 2 cases, he expected us to demo the saw sharpening stories. We chose them, but we had to show him that they were actually making us better.

      But I\’ve never seen an exec ask for less than 30%. Especially once they knew that most of that spend would go into the code: preventing bugs by cleaning up bug farms and poor design, fixing architectural problems, and the like.

      1. uh, whoops. I tried to do this is @patmaddox – oh well..

        How many execs has this been? Have you seen a correlation between authority level and budget allocated to saw sharpening? I'm thinking of a programming team manager or product owner that might say 20% for saw sharpening, whereas his/her boss might say 30-50%.

        Also I'm wondering how the language you use affects their thinking. short-term wins and long-term strategic value are boring compared to sharpening the saw, which is also a term used in Covey's 7 habits books. I suspect many execs would make a link, knowingly or not, and intuitively understand that sharpening the saw means investing in people. Improving employee efficiency and reducing variance translates into more short-term wins and more long-term value, with more predictability – which translates into good business.

    1. Of course I can't. No one can. 🙂

      Seriously, productivity is whatever your team means by productivity. It doesn't really matter how you measure it. Everyone has a feeling for it. It's something along the lines of "how much good stuff gets doen per unit time."

      Variance is simpler. Given two tasks that you expect to take about the same amount of time, how often do they actually take about the same amount of time? In a system with low variance, they are usually pretty similar. In a system with high variance, different tasks with the same estimate often take wildly different amounts of time.

      1. I am glad you use such "fuzzy" definitions, seriously. IMO that leads to far richer views of the situation and more fruitful conversations. Thanks.

  2. How many execs has this been? Have you seen a correlation between authority level and budget allocated to saw sharpening? I'm thinking of a programming team manager or product owner that might say 20% for saw sharpening, whereas his/her boss might say 30-50%.

    Also I'm wondering how the language you use affects their thinking. short-term wins and long-term strategic value are boring compared to sharpening the saw, which is also a term used in Covey's 7 habits books. I suspect many execs would make a link, knowingly or not, and intuitively understand that sharpening the saw means investing in people. Improving employee efficiency and reducing variance translates into more short-term wins and more long-term value, with more predictability – which translates into good business.

Leave a Reply

Your email address will not be published. Required fields are marked *