Technical debt is the name we give to those shortcuts we take when building software. It’s a clever analogy taken from the financial world. If your project is technically in heavy waters, nothing gets done and it will shut down gradually. If you can’t pay the mortgage on your house anymore because the Visa bills are too high, you’ll lose everything.
Most talks on technical debt are of the gloomy variety. There is usually a developer on stage preaching about the horrors of shortcuts gone wrong. The warning is always: avoid technical debt like the plague.
But just like in the financial equivalent, there can be big benefits in amassing technical debt. That pricy mortgage allowed you to buy your house after all. We call that an investment, not residential debt.
There is a big difference between borrowing for smart investments and getting frivolous loans.
So what about technical investment? When is it a great idea to get into technical debt?
If you skip refactoring because it’s Friday and the sprint closes, that’s generally a frivolous loan. You tell yourself you’ll do it on Monday, but something will come up. You’ve met the deadline, but debt has snuck into your code. It’s better to miss the sprint commitment and close the ticket when it’s done.
Here’s another scenario. You skip refactoring because it’s Friday and a big potential customer will attend the demo. You’ll dazzle them with this new feature even though the quality is subpar. Is it still better to only deliver when done? No!
There can be great reasons for taking out a loan. A commercial opportunity. A big demo. A proof of concept. An urgent patch. You don’t want to miss out on that just to keep your codebase pristine.
Know your current state.
A team should be aware of their solvability. Whether it’s JIRA tickets or TODO comments, make sure each of the shortcuts you’ve taken is documented. Give them a date and a little description of the reason why you took them. “How much debt do we have?” should be an easy question to answer.
Have a plan.
You need a payment plan. That means planning in those tickets and sticking to that plan. That means prioritising a few code-cleanup tasks every sprint. “When will we be free of debt?” should be an easy question.
Pay off early if you can.
When your team reaches the Nice-to-have tickets, ramp up the payback plan. You’ll deliver less new functionality, but you’ll improve the health and flexibility of your project for when it’s needed.
It’s better to have one ‘There will be Dragons’ component in your system than mediocre stuff scattered all around. If your product is flexible, except for one interface to a legacy system, you’ve still got a flexible product. You’ll know where to focus.
Technical debt that’s under control can be a great investment. It allows you to get ahead at crucial times. As long as you’ve made a rational budget, you’ll be fine.
You don’t take a loan for a new car just because you want one. You shouldn’t rush a product out of the door, just because the deadline is there either.
That doesn’t mean you should never buy a car.