3 minutes on... Technical debt

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.