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."
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.
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.
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.
Choosing a collaboration platform
Eight questions every IT leader should askDownload now
Performance benchmark: PostgreSQL/ MongoDB
Helping developers choose a databaseDownload now
Customer service vs. customer experience
Three-step guide to modern customer experienceDownload now
Taking a proactive approach to cyber security
A complete guide to penetration testingDownload now