Technical debt: an IT cost that keeps on growing

Business of IT: Poor programming practices, errors and rushed upgrades can create software that becomes slower and bloated with age. IT experts are starting to refer to this as "technical debt". We show how to identify, and tackle it.


Maintaining business software is not unlike running a car. In the first few years, there is a manufacturer' warranty, or support agreement. But after that components can become less reliable, and need to be replaced. And often the older the car, the costlier the service.

Enterprise software vendors do, of course, provide maintenance and often, new releases and upgrades as long as a support plan is in place. But that does not apply to custom, or customised software.

And even an off-the-shelf package can become harder to support, as its uses change and develop, new modules are added and others upgraded, and it connects to more data sources or other applications. The result for end users can be a steady and sometimes even a sudden decline in real-world application performance.

"This is an IT focused issue that has a huge impact on the business," says Stuart McGill, CTO at Micro Focus, an application management vendor. "Research suggests that CIOs believe they have a process in place to manage IT debt and reduce it, but if you delve into that, it is often based on flawed information."

Advertisement - Article continues below

Beyond your means: slipping into technical debt

Technical debt is a term coined by industry observers for the phenomenon of software that starts to cost more to run, or becomes less effective, the longer it is in use. The analogy might be with a ballooning interest charge on an unpaid credit card bill. And, like the credit card bill, technical debt often stems from previous over indulgence.

Here, though, the problem is not spending but programming shortcuts, inadequate software testing, temporary patches or workrounds that become permanent, and other poor development practices. In-house software, as well as applications developed on core technologies from vendors such as Microsoft, SAP and Oracle, can suffer from technical debt. Each time the software is extended, upgraded or adapted, unless previous coding errors are corrected, performance is hit. The software may not fail, but it will certainly run less well than it could.

"Unless you clear it out it's a growing problem, which can lead to higher costs," warns consultant and former HSBC IT executive Andy Givens. "Technical debt does increase over time. If you take the example of financial services, many want to launch mobile applications. But a lot of the information is in legacy systems. That is becoming increasingly complex."

Unless businesses address technical or IT debt, problems can pile on top of other problems, warns Givens.

But sometimes IT departments are largely unaware of the problem, with the first indication there is something wrong being when users start to complain about application performance.

"Why do companies allow known problems in their software? They are in a rush," says Jay Sappidi, senior director of research at software tools vendor CAST. "Compromises are made or the decision is made to add a new feature, and where they should rewrite code, they do a patch."

And, the increasing demands placed on IT, and the resulting software complexity, can cause real problems if coding shortcomings are not addressed.

Known knowns, and known unknowns

For IT departments, though, tackling technical debt might not mean removing all errors from software code. A ground-up rewrite of an application might be possible and even justified in some cases. But writing a new application from scratch, even with better development methodologies, creates the risk of creating new errors in place of the old.

Advertisement - Article continues below

Where a rewrite is either not needed, or not affordable, development and maintenance teams will need to prioritise the code they fix. This means identifying the most risky errors and workarounds, from an application stability point of view, and setting these off against the cost of correcting them.

Sometimes a relatively small error, but one which happens regularly, can be a big drain on business productivity. For others, lower-grade errors might have a low probability of damaging a whole system, or there might be known errors that are perceived as unlikely to cause a systems failure in practice, or if it does, the failure can be mitigated in another way, such as through a backup system.

The most challenging errors often are those that are unlikely to manifest themselves, but if they do, would have serious consequences. There, it may well come down to the judgment of the CIO, and maybe the board, as to whether the cost of fixing the issue is justified.

Diagnosis, then cure

But the first task for IT departments' software support teams is usually to analyse the health of their key applications, and to attempt to quantify the level of technical debt.

End users can be the best source of insights on performance problems. Has a key application started to perform less well, and are there other contributing factors, such as more users or a heavier processing load? If not, software code errors might be to blame. If an application has been upgraded or extended, the new code could have thrown up previously hidden errors, so a check against the software development and upgrade schedules should be part of the root-cause analysis.

Assessing technical debt itself, though, may be best tackled through a specialist software quality tool set. Vendors such as Cast and Compuware make quality-control tools that can examine programs automatically, and find some of the common, and less common errors, from recursive commands and unassigned variables to simple code duplication. Diagnostic software uses sophisticated algorithms to work through thousands, if not millions of lines of code in a few hours a task that is usually beyond the human brain.

Paying down the debt

Once the development or maintenance team has a list of the most problematic errors, and the business' priority list for fixing them, it is then a question of scheduling the repair work and ensuring better programming practice, so that errors, or technical debt, does not build up again.

And the greatest benefit of software quality tools is impact it has on development methods, once the core problems have been corrected. CIOs who have used software quality tools to trace particular operational problems, or to tackle technical debt, often continue to use them as ongoing development quality control tools.

Advertisement - Article continues below

Not only does this reduce the need for manual checking and testing of code, but it can help development teams to sharpen their coding skills and update their development methodology, especially where software quality is benchmarked internally or externally.

"To use the financial comparison, you can default and start again. But the debt will continue to climb unless you manage it," says Micro Focus' Stuart McGill. But there may be a pure cost saving from shutting down an application and the costs associated with it, or removing redundant code. "For a mainframe application, if you have 30 per cent of code not being used that is still costing you MIPS."

The result should be cleaner, more reliable code that is less prone to technical debt over its lifetime and if the process is done well, the cost of the tools should be paid back in months, not years.

Featured Resources

The essential guide to cloud-based backup and disaster recovery

Support business continuity by building a holistic emergency plan

Download now

Trends in modern data protection

A comprehensive view of the data protection landscape

Download now

How do vulnerabilities get into software?

90% of security incidents result from exploits against defects in software

Download now

Delivering the future of work - now

The CIO’s guide to building the unified digital workspace for today’s hybrid and multi-cloud strategies.

Download now

Most Popular

Microsoft Azure

Microsoft, not Amazon, is going to win the cloud wars

30 Nov 2019
Amazon Web Services (AWS)

What to expect from AWS Re:Invent 2019

29 Nov 2019

Raspberry Pi 4 owners complain of broken Wi-Fi when using HDMI

29 Nov 2019
Google Android

Samsung Galaxy A90 5G review: Simply the best value 5G phone

22 Nov 2019