Technical Debt

Before you continue reading, can you give a definition of technical debt? You might want to write it down.

I planned to facilitate the LADG session in 3 stages:

1. Agree a definition of technical debt
2. Agree aspects that are included/excluded from technical debt (for example, legacy code included; new features excluded)
3. Discuss ways people have dealt with technical debt

“Technical” debt?

Not once did I anticipate we’d find a solution to the problem, but I also didn’t anticipate a lengthy discussion about the term. ‘I don’t like the word “technical”’, started John, ‘Isn’t a better phrase “product debt” instead?’. He has a point: technical debt is often viewed as something that the dev team could have avoided, but product debt includes Product Owner decisions. ‘Or maybe just “debt”’ suggested another. One thing is for sure, it’s not as straightforward as I first thought.

Defining technical debt?

So, your definition? Something that has no immediate business value? Something that you have to persuade the business to take into a sprint?

And here opens the can of worms: my definition of tech debt includes short-cuts/hacks that got the feature out but have muddied the code base and legacy code that nobody understands/wants to touch. But where do you draw the line between a short-cut and not gold-plating code? What is legacy code? A dictionary definition of legacy is ‘of or pertaining to old or outdated computer hardware, software, or data that, while still functional, does not work well with up-to-date systems’. Although that seems to be a clear definition, ‘old’ and ‘work well’ are pretty shaky terms when old code from a feature done a few iterations back doesn’t work well with what you are trying to do today. Does it include bugs? Release process problems? Performance-related issues? Does that one need to be split to separate performance issues relating to hardware and those caused by bad code? We did get to some agreement though: it definitely doesn’t include de-prioritised scope, scope changes or new features.

How to deal with tech debt?

Options, but not options:

• Ignore it (the route many companies take)
• Wait until it hurts the business (and then blame the team)
• Continue increasing it by putting hacks on top of short-cuts (so you increase tech debt)
• Have better visibility of future requirements so you build up technical credit (may seem like a good idea to prevent some debt, but you are then building for a future that might change so you’d have wasted your time)

Prevention?

• Communicate the product vision
• Pair programming
• Discuss requirements before you build
• Write automation tests before working on stories

Stand up and be counted:

• Add the debt to your backlog
• Communicate your debt (see below)
• Link debt to up-coming user stories then tackle the technical debt when you come upon a story that touches that code (i.e. include resolving the debt as part of that new story)
• Add a certain amount of refactoring/resolving technical debt into each iteration (either as a percentage of stories or value of story points)
• Assign a sprint to tackling the debt
• Stop working on new features until tech debt is reduced
• Refactor little and often

Sounds too idealistic?

Unfortunately, not every company/Product Owner is smart enough to know that building up technical debt is going to hurt them in the future (if it isn’t already). So some of the above ideas, such as refactoring little and often / bringing some debt into each sprint, may seem idealistic.

If this is the case, I’d suggest you implement a debt matrix as used by one of our group. In short, it is visualising your debt for all to see. Especially anyone who is trying to sweep it under the carpet. Firstly, agree and accept that every team/company has some tech debt. Don’t be ashamed. It’s not always because of wrong decisions; sometimes the correct solution in our real world is to take a certain path – and that may incur some debt. Accepting that is the first step to recovery. And sometimes we do make mistakes. Hey, we’re human.

The matrix idea has an axis of complexity and another for business value. Plot each item against these two factors … then start to pick off high value items according to the time available. Even if your company has traditionally fought against spending time reducing technical debt, hopefully this visualisation will persuade them that getting easy, high value tech debt resolved is a great idea?  Then you just need to persuade them to let you chip away at the more complex high value items.

Do you have other ways of attacking your technical debt? Please let us know.