In programming, technical debt arises whenever you make a temporary choice that requires effort to correct at a later date.
This is probably the most common way to accumulate tech debt. Small businesses have tight website budgets. If they rely on the online presence, this can quickly catch up with them during the growth stage.
It’s especially common during periods of insane growth that require you to add features on top of the old solution. The first, budget website is something companies get before they really know what they need. As such, it might be full of features built on a hunch and places where developers had to cut corners to fit within the budget.
Building on these shaky foundations when time is of the essence leads to cutting even more corners. Growth can’t just wait until you’ve fixed the old issues – the new features need to be done, almost at all cost, and that’s how technical debt typically starts.
Quality of the code is another reason technical debt might creep up. It can feel a bit discouraging, especially when you make a step up to a developer or an agency that have higher standards. Why?
Most of the time, with higher standards comes higher price. Technical debt amassed by the previous contractor could appear very costly to pay off and you might decide to ignore it. But we know from the first example that this can spiral out of control.
We’ve all been there. A change makes it to the live site and something is broken. Nobody likes this, but it happens. Some code changes are so vast that it’s hard to catch everything. We employ both manual & automated checks to test that, but things slip by every now and then.
Especially when the site already struggles with some technical debt. But even in a debt-free scenario, you can launch a feature with a bug that will go completely unnoticed. The next time you build something on top of it, this will escalate like in the first example once again.
Development teams encounter technical debt for several reasons, both internal and external:
In short, technical debt is any component that detracts from the value proposition delivered by an agile software project—and there are plenty out there!
We distinguish 4 types of Technical Debt
Everything we do affects technical debt and we should be aware of the impact. Throughout every sprint, we need to know how much refactoring has been done and how much more is necessary. This can be measured by tracking hours spent on refactoring and the size of user stories in the backlog compared to the agile team’s velocity.
We need to plan for paying off technical debt in every sprint. It’s impossible to know the exact consequences of each change until it’s implemented. You still have an idea of what needs to happen down the road. This ensures that when problems arise, they don’t derail your team’s progress.
Ultimately, everything comes down to transparency. If the development team is honest about technical debt and acknowledges it, you will naturally incorporate tech debt into the sprint backlog. Bonus points if you can communicate and prioritise technical debt during sprint reviews!
While technical debt is a useful tool, it must be managed carefully. If left to grow unchecked, it can have a negative impact on the team, product and business.
Technical debt can be managed by paying it down with refactoring. By doing this, you’ll improve the codebase while reducing technical debt at the same time!
In conclusion, technical debt can have its merits as it may save a lot of time. It can help land a critical customer when the product is released early or achieve cost savings that can be invested elsewhere. – as long as we keep its existence in the back of our heads and allocate time to deal with it in the (near) future!
Have you encountered technical debts at the businesses you’ve worked for? Tell me all about it in the comments.
The Design Sprint is perfect for big challenges and audacious goals. But what about your daily “status report” meetings? They suck. We’ve all been there. Sign up for our newsletter and get immediate access to a PDF that will make them ten times better.
Originally published May 11, 2022 11:32:49 AM, updated September 3 2023.