Technical debt is a term used to describe the difficulty of working with low quality code or legacy systems. It's a metaphor that was originally used to explain why resources needed to be set aside to refactor software after its release – this means altering the internal structure of code, making it safer, easier and cheaper to modify, but without changing its external behaviour.
When organisations talk about the existence of technical debt in their technology systems, it generally isn't a good thing unless they employ strategies to address it regularly. In some cases, a certain level of technical debt might be accepted as a trade off against getting results faster. But it's worth bearing in mind the debt metaphor here – technical debt creates a kind of interest in the form of workarounds and engineering constraints that must be dealt with at some point. If technical debt is left unpaid, it only generates interest...
This is something organisations still struggling with legacy infrastructures will be all too familiar with. For example, they might want to develop a new service, or modify existing functionality, but their systems are so difficult to understand - let alone work with - that this becomes far more of a challenge than it should be.
Technical debt makes technology difficult to maintain, causes security risks, and holds organisations back from achieving their business aims. In order for an organisation to be agile, it must instead have adaptive core technologies.
Migrating legacy systems to the cloud, using modern, modular approaches to software engineering, and prioritising high code quality are all ways of minimising technical debt, as they help software engineering teams to design and build things cleanly the first time around. This creates a solid foundation for future success.
If engineers do decide to tolerate some technical debt due to time pressures — for example when the aim is to release an MVP as quickly as possible within an agile sprint — then technical debt may be tolerated, as long as it is returned to and dealt with later.
It all depends on the context.
Naming services in complex situations
How we use naming workshops as part of best practice for services in complex situations.
Read moreOur recent insights
Budget 2025 reveals how digital funding really works
Background: The Budget was announced yesterday, it’s not announcing big new programmes of work - it’s fine tuning how the government's fiscal policy supports existing policy objectives. There’s takeaways for all digital leaders from this announcement and some thoughts about that to do next.
Read more
Unlocking the benefits of AI for charities
How human-AI collaboration can help charities get true value from their data, turning insights into impact.
Read more
What's the future for open data in the UK?
A decade ago, the UK was a leader in open data, but its prominence has faded. We examine why the focus has shifted and what the future holds for the role of open data in the public sector.
Read more
