As scare stories go, IT advisory firm Gartner's estimate that 'technical debt' will amount to some £1.5 trillion by 2015 should be cause for most of us to lose sleep.
While the term summarises what is an endemic and very thorny issue, it can be straightforward to manage – at least, once it’s possible to see the wood from the trees.
Starting with the basics, what does technical debt mean? Computer programmer Ward Cunningham coined the phrase and as he explained: “There are plenty of cases where people would rush software out of the door, would learn things but never put that learning back into the programme. By analogy that was borrowing money thinking that you never have to pay it back.”
There’s little point in pretending that technical debt won’t continue to grow. To extend the loan analogy, there is a need to move quickly and with ‘borrowed money’, you can do things earlier than you might otherwise, but if you fail to pay down the loan you end up saddled with ‘interest’ that, over time, will hinder the ability of an organisation to function.
For example, a large credit card company has tried three times to migrate its core systems on to a brand spanking new application and failed each time. They have now realised that stage one is to fully understand what the current application does in detail before attempting to rewrite and enhance the application.
The reality is that people are busy doing the new and don’t have time to look back at the old. Many systems have been acquired over the years due to mergers and takeovers and, as is well-known: ‘old systems never die – you just build another interface to it!’. In addition the constant outsourcing and loss of core IT business knowledge means that the original system expert is rarely still around.
So what practical steps can be taken to work with, or around, technical debt? Ideally, teams would repay the loan by refactoring the programme after the rush to get it up and running and documentation would be updated so that it is clear, usable and ready for the next addition of functionality.
Adding features without adding understanding the code’s architecture jeopardises all future efforts to work with it. However, with the best will in the world, this technical debt has often been accumulating for years and it is unrealistic to go back and re-build all the missing documentation. So what can be done?
Fortunately, with a small change of emphasis towards becoming more focused on the data flow in and out of a system you can now payback that debt, giving teams a fighting chance of understanding how systems work. This is significant because it avoids having to embark upon the impossible – namely, a wholesale re-documentation exercise.
By using the right data profiling software, it is possible to scan and understand the inputs and outputs of processes without having to reverse-engineer the entire process. In essence, data is the life blood of a system and if you can understand, document and simulate that then you have a fighting chance of paying off the technical debt.
Huw Price is the founder and chief technical architect of Grid-Tools Ltd.