What is technical debt and what should you do about it?
Everyone has some form of debt, and the tech world is no different. In today’s move-fast-and-break-things tech climate, technical debt has become a fact of life for many software developers.
Like financial debt, you need to pay off your tech debt. The longer it’s left, the worse it can get. But does that mean that it’s always a bad thing? Something to avoid at all costs?
We explore the realities of technical debt, what it is, why it happens, and what — if anything — you should do about it.
What is technical debt?
Technical debt is a programming concept that stems from making ‘quick and dirty’ development decisions. It reflects the implied costs of reworking the code in your program due to taking shortcuts.
Most commonly, technical debt comes from dashing out code that’s fine for the short term, but can’t scale with you long term. The implied cost of your quick and dirty code includes the time, money and other resources that you’ll need later down the line. (For reworking that easy-option code into the best overall solution.)
So, what is technical debt? It’s the interest you pay for taking the easy short-term development option, over the longer and harder – but ultimately cleaner – option.
Why does technical debt happen?
There are several reasons developers might choose (or be told to use) the easy solution instead of the best one when they code.
- In a rush
The most common reason for technical debt is a rush to get the software to market. Developers dealing with the dreaded ‘how long will it take’ question may find themselves under pressure to take coding shortcuts to get the job done sooner. So, they take the easy option in haste. That can cause problems later – from bugs to spaghetti code.
- Bad code
Poorly written code or simple oversight by programmers is another culprit behind technical debt. Everyone makes mistakes from time to time. When this happens in code, technical debt begins to accrue. Bad code isn’t scalable, and the problem will eventually need fixing.
- On purpose
Sometimes, you might choose to go into technical debt for strategic reasons. What makes this different from purposefully choosing the easy option under duress is the level of understanding needed. You should know what the cost will likely be, and when you intend to repay it. This is like
taking out a technical loan, and it can be useful.
Should you avoid technical debt?
Ultimately, most technical debt comes from a lack of long-term thinking. The people in charge want or need results in the short term. It’s not until much later that they consider the (often hidden) costs of forcing those results.
Technical debt isn’t inherently bad. But, like financial debt, it can cause serious problems if you don’t pay it back.
This is because choosing the easy option over the best one is a short-term fix. In the long term, the weaker option leads to weaker software. It might not be able to support the growth of your business, or new functionality that you want to add.
Can you ever embrace technical debt?
However, being open to accruing a little technical debt can be beneficial. (That is, if you manage and understand it from the outset.)
After all, ‘quick and easy’ coding can help you get something to market sooner to nurture your customer base. Plus, it can act as a placeholder for a planned feature or cost that you want to defer until next month.
You needn’t run screaming from every easy option, forever deferring your software deadline because it’s not perfect yet. ‘Done is better than perfect’ is an approach that has merit for a reason.
So, you don’t always need to avoid technical debt. What you should avoid is taking out a technical loan without planning or consideration. Instead, be aware of costs and time you’ll put aside to pay it back.
What should you do if you have technical debt?
No matter whether you have it by accident or by choice, it’s imperative that you allocate time and strategies to pay off any technical debt.
- Better now than later
Remember, technical debt happens due to choosing weaker code— meaning that it’s a temporary fix. The sooner you rework it, the sooner your software can grow with your customers. Plus, leaving it too long can result in customers finding faults in your software.
- Little and often
When reworking your code, it’s best not to try and do it all in one go. It’s stressful for your team and creates the same rushed environment that caused the debt in the first place. Instead, set aside time in each sprint or over several sessions for fixing some of the debt.
- A team effort
You should also make paying off your debt a team effort. That is, make sure that everyone (regardless of seniority or other responsibilities) helps rework the code. This can improve the dev office atmosphere by promoting teamwork. Plus, it helps newer team members see more of the existing codebase.
Treat it like a technical loan
Technical debt is sometimes a necessary evil when it comes to software development. It doesn’t have to be a bad thing. It’s not always avoidable, nor should you always avoid it.
The best approach is to treat it like any other kind of debt. If you choose when you take out a technical loan, and when you plan to pay it off, technical debt isn’t a problem.
