So the NHS got hacked. Jeremy Hunt saved £5m a year in payments for extended Microsoft support and now look what’s happened. This reminded me of something important.
Software engineers have a concept of “technical debt” that is worth remembering. Technical debt arises when you decide to put some work off to the future, so you can get on with something more important in the moment. So there was that annoying bug, but you thought it was more important to finish the integration with Salesforce and your customers definitely thought so. You knew you needed to do the security audit, but there were all those bugs to tackle. You wouldn’t have designed the whole thing this way, had you known anyone would use it, but rebuilding the core of the application? There are more immediate concerns.
It’s like debt for a number of reasons. First of all, you’ve got to pay it off in the end. If you don’t do the security audit, one day you’ll be on the news. If you don’t do the big redesign, one day you’ll hit some sort of limit. If you don’t keep up with the maintenance, one day the whole project will just be too crufty to advance further.
Secondly, though, the optimal level of technical debt is not necessarily zero. Debt is useful. We incur technical debt when we choose to prioritise some tasks over others. This allows us to commit more of our resources to goals we consider important, on condition we eventually get after the others. This has an important consequence.
An organisation can put up with more technical debt if its ability to pay it off – to fix it – is also growing. If the inventory of deferred work grows faster than the capability to do it, though, it’s heading for ruin.
And finally, as with any kind of debt, it’s very important to recognise that it exists and to account for it. One of the best ways to give a false impression of success in business is to find a way to borrow without accounting for it. Leverage increases returns.
With technical debt, you’re essentially borrowing from yourself. The flow of cash that would otherwise have been used to retire the technical debt is available for some other purpose. This looks like there’s been a saving – a reduction in the actual costs of doing business. But in fact, there is no saving. Work that needs doing has not been done. It will need doing in the future. Swapping future money for money today is the very definition of debt.
As I say, the optimal level of technical debt is not zero. But let’s think about this more broadly.
When institutions want to save, especially governments, the first thing they do is cancel big capital projects. That’s easy – they are well defined lump sums. The second thing they do, though, is to cancel maintenance. The nice thing about cancelling maintenance is that stuff usually works for quite a while. You have the cash, and the repayment is in the future. Debt, see? And wonderfully, you don’t need to book it anywhere. When John Major privatised the railways, Railtrack plc reduced the track mileage it replaced annually by two-thirds. Not surprisingly, it managed to pay dividends right up to the bitter end, borrowing from its assets by running up technical debt.
So. Remember when the fella said he was fixing the roof while the sun was shining?
In a rail context, it’s also worth noting BR itself was (almost certainly, although its asset registers were barely extant and its books run on a solidly cash basis) running up a technical debt on maintenance: at least for the Thatcher decade of subsidy cuts before Railtrack took over, and quite possibly for its entire post-Modernisation Plan existence.
This is one of the reasons why comparisons of spending/subsidy under BR versus Network Rail (which keeps a detailed and mostly accurate asset registry and accounts for depreciation) are extremely shady.