Technical Debt – Can it be eliminated or just reduced?

Where there is code, there is technical debt. You can try and minimise it, you can try and avoid it, and you can imagine a world where it doesn’t exist; but that’s wishful thinking at best. Can it be completely eliminated? Probably not. Can it be kept to a minimum? Absolutely! Let’s see if we can’t figure out how.

What is technical debt?

Technical debt occurs when you decide to make a quick fix now, at the risk of creating more work later. You ‘borrow’ the time you would spend creating a more comprehensive solution to a problem now, with the understanding you’ll need to ‘pay back’ that time later.

Technical debt is often accrued in the face of looming deadlines. If you promised your customers, your investors or any other important stakeholder, that something would be available by a certain date, it may be worth skimping on tidying up code, producing adequate documentation, or anything else that gets you across the finishing line.

Anyone even tangentially involved in software development will understand this pay off. A quick fix or cut corner can keep your product up and running, your release schedule adhered to, and business goals met; but you’ll have to pay the piper at some point.

Why is technical debt bad?

In many cases it isn’t. As with traditional debt, there’s perfectly valid reasons why you would want to borrow something now and pay it back later; whether that’s money or time. So long as you pay back what’s owed promptly, you should be fine.

So when does technical debt turn bad? When you can’t keep up with the interest!

Just like borrowing capital, technical debt charges interest. The time you saved implementing an inflexible but speedy fix could, and often does, result in extra time being spent creating a proper resolution down the road.

That may be catching up to the work you missed to meet a particular deadline or achieve a given business goal. It might mean going back over hastily written code, or it could be cleaning up less than perfect data sources.

So long as you plan for this and understand that the technical debt needs to be paid back, you’ll be in good shape. But if the rework of the quick solution you made last month bumps up against this month’s deadline, your technical debt can start charging serious interest.

This month’s deadline looming might encourage another quick fix, on top of the previous quick fixes you’ve made. This is where exponential debt can appear and send your development into a downward spiral. Because, of course, next month’s deadline is only a month away and you’ve got three months work to do before then!

How can technical debt be reduced?

As with all endeavours, this is going to depend on the company, the people in it, business goals, and the resources available. That being said, there’s a few steps that anyone can take in an effort to reduce technical debt.

Own the fact that technical debt exists

It might be a cliché to say ‘the first step to solving a problem is acknowledging it’, but it’s a cliché for a reason. Your first and best step is to accept that technical debt is a thing, and then you can work on solutions.

As we’ve discussed already, technical debt isn’t necessarily a bad thing. If you try to sweep it under the rug it will come back to bite you. But, accepting it as a necessary evil means you can start to work with it and not against it.

Acknowledging that some deadlines can only be met by cutting corners, means you can allocate resources to coming back around and filling those corners in. The repayment of technical debt becomes part of any potential release schedule and one you can plan for.

Make documentation a priority

A quick fix becomes a problem when you don’t properly understand it moving forwards. Whether that’s because there’s movement within your teams or a key member leaves, not knowing the cause of your technical debt will always lead to its growth.

Wherever a corner might be cut, don’t let it be in the creation of documentation. Reach your goals and deadlines however you can, but make sure in future you can easily look back and catch up on anything that could have been done more thoroughly the first time around.

Replace systems entirely

This might feel like a drastic measure, but understanding when to cut your losses can be a vitally important skill to have. One major problem with technical debt is that it’s all too often tied in with the sunk cost fallacy.

A system that’s grown overly complex and requires unmanageable amounts of resources to update is one that might just need to go. When the interest on your technical debt gets overwhelming, it’s probably time to make the switch.

This requires a radical thought process though and it’s easy to understand why it can seem so unconscionable to management. If you’ve put ‘x’ amount of money into a system or platform, you want said platform to give a return on that investment.

But looking at what has been put into a system ignores the bigger question of what might be put in in the future. Two more years of troublesome development, missed deadlines and frustrated developers could cost magnitudes more than adopting a new system that better fits your needs.

What’s the bottom line when it comes to technical debt?

As with all aspects of business, there’s no cut and dry solution to technical debt. And, as we’ve discussed, there often doesn’t need to be. As long as your documentation is on point, your planning takes into account the repaying of technical debt, and the weight of technical debt doesn’t outweigh the benefits of any particular system, you’re all good.

So, borrow wisely, repay the time you owe, and with any luck you’ll achieve great things.