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.

Debt

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
Advertisement - Article continues below
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.

Advertisement - Article continues below

"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
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.

Advertisement - Article continues below

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

Advertisement - Article continues below

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
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

What you need to know about migrating to SAP S/4HANA

Factors to assess how and when to begin migration

Download now

Your enterprise cloud solutions guide

Infrastructure designed to meet your company's IT needs for next-generation cloud applications

Download now

Testing for compliance just became easier

How you can use technology to ensure compliance in your organisation

Download now

Best practices for implementing security awareness training

How to develop a security awareness programme that will actually change behaviour

Download now
Advertisement

Most Popular

Visit/policy-legislation/data-governance/354496/brexit-security-talks-under-threat-after-uk-accused-of
data governance

Brexit security talks under threat after UK accused of illegally copying Schengen data

10 Jan 2020
Visit/microsoft-windows/32066/what-to-do-if-youre-still-running-windows-7
Microsoft Windows

What to do if you're still running Windows 7

14 Jan 2020
Visit/hardware/laptops/354533/dell-xps-13-new-9300-hands-on-review-chasing-perfection
Laptops

Dell XPS 13 (New 9300) hands-on review: Chasing perfection

14 Jan 2020
Visit/operating-systems/25802/17-windows-10-problems-and-how-to-fix-them
operating systems

17 Windows 10 problems - and how to fix them

13 Jan 2020