Pay down technical debt to modernise your technology estate

Imagine this scenario. Your CEO tells you the organisation needs a complete tech overhaul, then gives you a blank cheque and free rein. He tells you to sweep away the old and usher in the new. “No shortcuts, no compromise!” he cries. “Start from scratch and make it perfect!”

And then you wake up. As we all know, this scenario is pure fantasy. Instead, IT leaders are faced with a constant struggle to keep up with the needs of the business, using limited resources, time-saving shortcuts and legacy systems.

That’s the normal way of things and it can be a recipe for serious technical debt.

What is technical debt?

You’ve probably heard the term “technical debt”, even if there’s no agreement on what exactly it means. 

At its simplest, technical debt is the price you pay for an unplanned, non-optimised IT stack. There are many reasons for technical debt but in every definition, the debt tends to build over time and become more complex to solve.

The phrase is intentionally analogous to financial debt. When you buy a house, you take out debt in the form of a mortgage. You get instant access to the thing you need – a home – but there are consequences down the line in the form of interest payments.

As the metaphor suggests, technical debt is not always bad, just as financial debt is not always bad. It can be useful to do things quickly, as long as you’re prepared to tackle the consequences when they inevitably emerge. Unfortunately, lots of organisations take on the debt without thinking about the challenges to come.

The challenges of technical debt

How does technical debt come about? The simple answer is, in the normal cut and thrust of running a busy organisation.

Source: McKinsey & Company

  • You create a temporary fix to a software problem and then don’t have time to design a better one. Over time, the temporary fix becomes a permanent part of your solution. The sticking plaster becomes the cure. 
  • Your development teams are put under pressure to get something to market in super-quick time, to grasp a time-sensitive opportunity. They get it done – brilliantly – by making something that works well for the task in hand, but time-saving shortcuts slow up other systems in the longer term.
  • Finance refuses to replace legacy systems that just about work, even if they can’t offer the flexibility or speed that a modern digital-first organisation needs.

In each case, complexity builds. One quick fix after another undermines the efficiency of your wider technology stack. Solutions work in isolation when they need to work together. Systems creak under the pressure of outdated or over complex code.
What level of debt does this ad hoc activity accumulate? According to research by consultancy Mckinsey, tech debt amounts to between 20% and 40% of the worth of an organisations’ entire technology stack. The study also found that those with the lowest technical debt performed better.

Source: Tech Target

How to manage technical debt

So what can you do about it? In short, the way to manage technical debt is to pay it off. Not necessarily all of it, because some debt is OK. But it should be nearer 5% than 40%.

The first thing is to understand what your technical debt is, and what’s causing it. Some of this you may instinctively know, such as the slowdown in productivity caused by legacy infrastructure.

Elsewhere, it can be relatively straightforward to identify the symptoms of an overly complex or outdated system:

  • When an engineer is assigned a support ticket, how long does it take to complete the task? Are average completion times increasing? If so, you’re accumulating technical debt.
  •  Are you having to fix your fixes? Maybe an application requires reworking one week and then again a couple of weeks later. In this case, debt is building up.
  • If you often have to develop applications and solutions quickly, or patch legacy software to keep it running, you’re also likely to be accumulating technical debt. 

In business-critical applications, it’s worth analysing the quality of the underlying code. It might have been fine five years ago, but half a decade can be a long time in technology. Writing modern code in a more efficient language will likely create significant efficiencies.

Don’t try and do everything

Identifying and reducing technical debt is a resource-intensive task. But it can be made manageable if you focus on evolution rather than revolution.

Mckinsey cites the example of a company that identified technical debt across 50 legacy applications but found that most of that debt was driven by fewer than 20. Every business is likely to have core assets that create most of its technical debt. They’re the ones to focus on.

When you have identified the most debt-laden solutions, put the support, funding and governance in place to pay down the debt. Create meaningful KPIs and keep to them. Think about how to avoid debt accumulating again after modernisation projects are completed.

Elixir and technical debt: Commit to modern coding

At the core of that future-proofing effort is code. Legacy coding techniques and languages create clunky, inefficient applications that will soon load your organisation with technical debt.

One way to avoid that is through the use of Elixir, a simple, lightweight programming language that is built on top of the Erlang virtual machine.

Elixir helps you avoid technical debt by creating uncomplicated, effective code. The simpler the code, the less likely it is to go wrong, and the easier it is to identify faults if it does.   

In addition, Elixir-based applications always tend to run at the optimal performance for their hardware environment, making the best use of your technology stack without incurring technical debt. 

In short, Elixir is a modern language that is designed for modern technology estates. It reduces technical debt through simplicity, efficiency and easy optimisation. 

Want to know more about efficient, effective development with Elixir, and how it can reduce your technical debt? Why not drop us a line?  

Keep reading

Why do systems fail? Tandem NonStop system and fault tolerance

Why do systems fail? Tandem NonStop system and fault tolerance

Explore the NonStop architecture's influence on Elixir, Gleam, and Erlang developers. Learn about modularity, fault containment, and process-pairs design for resilient software systems.

Erlang Concurrency: Evolving for Performance

Erlang Concurrency: Evolving for Performance

Erlang’s concurrency model, built for scalability, now competes with C and Rust in performance, powering messaging systems and large-scale platforms.

Elixir, 7 steps to start your journey

Elixir, 7 steps to start your journey

Embark on a journey into Elixir with our series "Elixir, 7 Steps to Start Your Journey" by Lorena Mireles.