Technical debt

Be aware of your technical debt

7 May 2021

Application modernization

Borrowing money costs money

Technical debt is a way of describing something that hasn't yet been resolved and that circumstances cause you to defer as a 'think about it later' item. You complete something, for example due to an unexpected situation or a deadline, but at the same time you build up a debt with respect to things that still need to be dealt with. In software development, technical debt is the price you pay for the extra effort you will have to make in the future because you consciously or unconsciously do not always (or cannot) go for the best or ideal solution. Sometimes you have to choose the solution that is most acceptable at that time. In fact, it’s a kind of overdue IT maintenance that you accrue by taking shortcuts. Rectification will therefore entail an additional cost in the future. 

Technical debt is a bit like taking out a financial loan with a bank. You incur a debt so that you can achieve something in the short(er) term and reach your goal more quickly. There’s nothing wrong with this in itself, but the longer you wait to repay, the more debt you accumulate and the higher the interest you will have to pay. In other words, borrowing money costs money; the same applies to technical debt. Some also liken technical debt to Tetris, the game with the blocks, but in the form of software. The faster the blocks start falling, the greater the chance of gaps (i.e. technical debt) in the structure, possibly up to the point that the situation becomes unsustainable.

Legacy applications are a typical example of this. although technical debt is also built up in lean and agile developments - but more about this in a subsequent blog post. Organizations often wait too long to update older systems, with the result that the threshold for revamping or modernizing becomes so great that they often no longer dare to start. The reasons are diverse and often intertwined: a tangle of outdated or illegible code, so-called 'spaghetti code' that no-one dares to touch; outdated databases or components; poor extensibility; lack of documentation or the right talent; etc.


Innovating with the brakes on

It is of course true that the sooner you tackle and resolve problems, the simpler and cheaper they are. For example, a bug fix at the beginning of a project costs just 10% of a bug fix at the end. Or vice versa, the longer you continue to push out certain issues, the more complex these become (exponential factor 2.1) and the more they cost. You may even reach a point where they cannot be resolved. In this way, technical debt slows down progress, and that’s something you should try to avoid at all times. Especially when digitalization and modernization are a prerequisite for survival.

A company that spends more than half of its IT budget on integrations and 'repairing' legacy systems is likely to end up in a technical debt spiral in which it only pays interest, due to the IT legacy from the past. When a company operates on a modern IT stack and has few technical debts, almost all of its technological investments can focus on future-oriented solutions and strategic innovation, and thus create added value for the entire organization. Most companies are somewhere between these two extremes. What it boils down to is reconciling short-term and long-term – running the business and changing the business – in a positive digital flow.

Watch out for the elephant in the room

It has to be said, technical debt is not necessarily a bad thing. Incidentally, you can never completely exclude or prevent technical debt. Projects need to be able to make progress and you’re faced with certain deadlines or temporary constraints, which means you have to change gears and sometimes take a shortcut.

However, it is important to be aware of the technical debt you are accruing and plan to do something about it with every choice you make in the development process. In this way, the level of technical debt remains acceptable and the short-term solution or shortcut can be converted into a structural solution in a reasonable period of time. Technical debt should not become a blind spot or the elephant in the room that no one wants to see.

Nevertheless, there is often a discrepancy between awareness and effective action. A study conducted by McKinsey1 shows that CIOs are well aware that there is technical debt within their organization and that it is increasing. In practice, they actually spend little or no budget on doing something about it. As a result, they burden the organization with a technological legacy that can sometimes be very difficult to get rid of. The study also shows that if budget is spent on technical debt, it will more likely to go to new projects in order to prevent the accumulation of technical debt there, and less to older legacy applications.

Where does technical debt actually come from?

The origin of technical debt can be found at different levels: strategy, architecture, talent and processes. For example, a strategic driver may be that a company’s business strategy has not been properly clarified, so the IT department does not know how to deal with this or how to preclude it. Maybe IT and strategy are not aligned well enough, so the focus is on the wrong IT initiatives. Or there is a mismatch between financing and strategy, in the sense that you want to do something but don't have the funds for it. Strategic acquisitions and takeovers can also increase the complexity of the IT landscape and processes, with all the associated risks of technical debt.

On the architectural front there are also parameters that play a role and can give rise to technical debt. It's said that 70% of IT systems are still running on outdated technology. In other words, there are still quite a few legacy systems in the application landscape of an average organization, and in any case they continue to generate costs for the business. Heavy customization and monolithic blocks of code can also drive technical debt, as well as poor data models and data quality or not using standards and APIs.

In addition, software is still mainly made by people. Lack of knowledge, skill and even motivation can also be a cause of technical debt. Teams that do not work well together, or even not at all, so one team creates technical debt for the other.

Finally, there are also internal processes that can be a cause of technical debt. Poor prioritization of things to be developed, poor development and maintenance processes that result in poor code quality. For example, there is little automation, so a lot of test work still has to be done manually, which increases the risk of errors. Unstable IT operations, poor disaster recovery, inadequate monitoring, conflicting or missing documentation can also lead to IT teams working blind, and thus generate technical debt.

pay off

How can you pay off your technical debt?

The best way to pay off technical debt is by not creating it, but we all know that this is virtually impossible. Sitting on a mountain of technical debt is not an option either, for the very reason that it puts a brake on progress and innovation.

In practice, modernization is the main way to tackle legacy applications and processes and thereby eliminate technical debt. As mentioned in the previous blog post, things are looking up for application modernization in the sense that technologies such as the cloud, big data and IoT make modernization easier and more efficient and help your company move forward faster, so that the apparent obstacles do not outweigh the benefits this brings.

But getting back to the discrepancy mentioned earlier: organizations need to be aware of technical debt in the first place, the fact that they should monitor it continuously, and that they should try to eliminate it over a reasonable period of time. Only then can they modernize efficiently and keep the cost of modernization under control. Identifying technical debt is important for the development of a modernization strategy and the degree of automation therein.

Not sure where to start with debt repayment? Our multidisciplinary team of application consultants will work with you to design the right action plan. We can deploy our expertise and consultancy at various levels, such as improving the strategic approach and architectural planning, optimizing skills and prioritizing processes, including change management, training and coaching.

(1) McKinsey Survey of tech debt among 50 CIOs, July 2020.

Don't take your modernization journey on your own

We are ready to transform and optimize your applications and IT workloads and make them future-proof.  

Discover all our blogs
Read more

Subscribe and receive our blogs in your mailbox