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.