Technical Debt in a Technology Strategy

When starting out on a new enterprise, whether you’re setting up your own company or going freelance, setting up a new coffee shop or building your first SaaS business, you’ll be using software. You might need order management software, website building software, software for keeping those sales leads in order. The modern business can’t operate without software.

If you’re creating a SaaS product you’ll have to form a strategy whether you’re using on-shore of off-shore teams, what technology to build in and which data centre provider you’ll host with, how your technology supports your business and, often overlooked, how you handle Technical Debt…

What is Technical Debt?

To give you a non-development example. If I have an electrician (we’ll call her Sally) re-wire my house the moment they walk out the door, I have technical debt. When I need a new plug added, Sally knows what she did and can probably quickly add it. If I ask a new electrician (let’s call her Bob) to come on in, he’ll have to dig through a whole load of wires, probably moan that the previous electrician did a bad job, and it will take him three times as long as it would have for Sally to add the plug, because he has to figure it out.

This is technical debt. If Bob has to spend more time understanding what’s happened before than actually adding the plug, then you have technical debt in your wiring.

I’ll push the analogy a bit further. If I want a new electric cooker into my kitchen, Sally may tell me we need to completely re-wire the whole kitchen because the wires she put in won’t take the load. She did not anticipate the new cooker. This is technical debt.

Fundamentally the underlying codebase wasn’t designed to take the load of the new feature. She’s got to deal with the technical debt, re-wire the kitchen with a bigger cable before I can have my electric cooker installed.

From a software perspective you have a technical debt problem where:

• The original implementation is so complex that a new developer takes more time working out what happened before than adding your new feature
• The original implementation fundamentally cannot support the new feature you are wanting to add
• You identify an issue or a bug that isn’t a problem right now, but will be a problem in the future

The most important thing to realise is as soon as your developers start writing code, you will have technical debt. Fundamentally it comes from choices made. How much time do you spend documenting, cleaning up code, refactoring to make the code more readable and easier to understand vs getting your feature out to market. When you make a choice to stop developing and get the feature out to market you introduce technical debt.

Technical debt can impact your company, much like financial debt. If you don’t deal with it and routinely pay it off, it grows. In the worst case it can react like compound interest, with the complexity of the code becoming exponentially worse over time, because the original debt was never reduced (in tech talk – refactored).

Whilst too much financial debt can sink your enterprise, technical debt is unlikely to sink the ship, but it can cause you significant problems around your agility and profitability. If you don’t have a plan to deal with bugs you’ll be reacting and fighting fires at the worst possible points. In the best case your development team is spending more time keeping your product running than building new features, in the worst case your product is off-line and you’re losing customers.

Solving Technical Debt With Strategic Planning

To ensure you don’t run into these problems you need to have a strategy on how much time you’ll spend paying off tech debt. Too little time and you’ll end up having to re-write the whole application again in the future. Too much and you won’t deliver new features to your customers.

The key to your strategy is agreeing with your development team how much time you want to spend and monitor the progress. Some teams prefer to address technical debt in a single sprint. Ensuring every two or three sprints that the team focuses on the health of the codebase rather than adding new features.

Alternatively, you could work with your team to spend a little amount of time gently re-factoring your code on every story. This is sometimes called code-gardening, as it’s a little like pruning. You should do it often and regularly to keep everything under control and healthy. The ideal is somewhere in between the two, getting your team into good practices will ensure your technical debt is managed, but there will always be those times when allowing a general focus on debt will be more efficient.

Another alternative is to not deal with technical debt. If your focus right now is to grow and deliver new features to be the first to market, then it’s perhaps the right decision to grow your technical debt. You’ll just need to ensure you allow more time further down the road, to address those issues. In some ways it’s like taking a financial loan out, ultimately you need to pay it off.

If this is your choice make sure you communicate it to the team. There’s nothing worse than a group of grumpy developers who don’t know that you have a plan with the technical debt and you understand their need to improve the quality of the code. Open and honest communication will help you a long way.

Regardless of the approach, you take make sure your team are doing the following:

• Capturing technical debt, and are regularly raising their concerns to you early
• Are on-board with the big picture, so they can work out if they need to engineer for the future, or deliver short term goals with the understanding that you will address those short comings when you add the future needs
• Implementing good code gardening with sensible pruning as they deliver new features

Monitoring The Technical Debt Strategy

Once you have your strategy in place it’s essential to monitor it. You may have decided to only deal with tech debt every 6 sprints, but this may not be enough, alternatively you may be fixing issues every sprint and over servicing your debt. To get an idea of how well things are going you can monitor some basic KPIs:

• Number of Tech Debt stories per sprint
• Number of Feature stories per sprint
• Speed of delivery of features

Through tracking the number of tech debt stories vs number of features you can see how well your ratio is to understand if you have the right balance. Running a software business can be fraught at the best of times so it’s important to keep an eye on this balance.

With tracking the speed of delivery in new features you can monitor if your codebase is becoming burdened with tech debt. If similar feature requests are taking longer and longer to delivery, this is very much a red flag that your codebase has a lot of debt and your team are struggling to work with it.

However you and your team choose to deal with technical debt, remember that this is just one part of your technical strategy and shouldn’t be all consuming. A good technical strategy factors in technical debt but is not solely around technical debt.