‘Legacy’ is a word familiar to many in the technology sector, with terms such as legacy components, legacy infrastructure and legacy code covering just some of the challenges that can occur as technology gets older. The problems that come with legacy technology may include products that are no longer supported, users don’t have the expertise to maintain them, or they may not be compatible with the rest of the tech stack in an organisation, the impact comes in the form of ‘technical debt’.

The term was first coined by programmer Ward Cunningham (who developed the first Wiki and is one of the authors of the Agile Manifesto, which sets out the principles many software developers use to guide their work). As he explained with a useful finance analogy, “With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea; I thought that rushing software out the door to get some experience with it was a good idea, but that, of course, you would eventually go back, and as you learned things about that software, you would repay that loan by refactoring the program to reflect your experience as you acquired it.”

The Bottom Line

In the case of software, technical debt is often a moving target. Whilst something may be deployed that’s cutting edge, it can become out of date quickly, adding to the debt burden. That’s why Operating Systems, Frameworks (such as .NET, Java, Node) and packages (i.e. for database access) get patched and upgraded on a regular basis. Windows, for example, gets patched at least once per month, with ‘Patch Tuesday’ becoming the unofficial name for when Microsoft and other vendors release their updates.

When referring to technical debt, we sometimes talk about 'paying interest'. If something hasn’t been built optimally, for example, if a platform upgrade is pushed back, or if a decision is taken to put off documenting a process, then the organisation in question may suffer a performance hit or a security hole within its IT systems.

As a result, when focusing on IT investment planning, organisations should assess the risks,  look at the costs to remediate and weigh them up against other priorities. The bottom line is that for any company that relies on technology, this debt is very real, with company valuations, investors and other stakeholders very interested in the level of technical debt a business might carry, and when that debt must be repaid in the form of new technology investments and upgrades. However these issues manifest themselves, kicking investment down the road can easily add to the final bill.

Debt relief

In tracking and managing the cost and impact of legacy technology, it’s useful to compile a technical debt log. This document should be owned by a project manager because they are ideally placed to put measures in place to pay the debt down. In practical terms, items should be prioritised by impact, severity and information about what happens if the item is left unresolved.

Here at IJYI, we’ve built considerable experience in helping clients understand their exposure to technical debt and how this could affect the performance of their systems going forward. We also help build technical debt logs, carry out priority planning and also help organisations fully understand cost and time impacts to remediate.