Banks' payment failures expose the fragile complexity of our digital world
|
Version 0 of 1. Yesterday, Natwest and Royal Bank of Scotland suffered the second catastrophic payment failure in as many years, with millions of shoppers unable to use their credit or debit cards on the busiest online shopping day of the year. Last time their payment system collapsed, in June 2012, the culprit was eventually found to be a botched attempt at routine maintenance of the IBM mainframe, which handles millions of accounts. Customers were locked out of their accounts for three days. This time the company has not yet confirmed what happened, but it has ruled out cyber-attacks as a cause, and has also said that it was not overwhelmed by a large volume of activity on "cyber Monday". It seems outrageous that a company whose systems were so unacceptably flawed a year and a half ago should fall prey to the same problem again, but it underscores the Byzantine complexity of the digital networks on which our day-to-day lives rest. In the physical world, the foundations of our lives tend to be relatively simple. The beautiful sweeping glass adorning the world's latest architectural masterpiece may have required cutting-edge tools to engineer, but the load-bearing struts are still concrete and steel. And getting high-speed trains to run safely at 300km an hour is a technological marvel, but Isambard Kingdom Brunel would still recognise the wheels and track as essentially the same as those used in his day. When we move online, the opposite tends to happen. The shiny edifices perched on top of our digital infrastructure are simple to build, and rarely too difficult to troubleshoot. But the back-end of our biggest networks, where the actual work is done, are tangled webs of technology, which even the best developers struggle to unpick. It's not just banks that suffer as a result. The website set up to administer the Affordable Care Act in the US – healthcare.gov – has been besieged with problems since its launch. Even after two months of fixes, the site still has catastrophic errors. At the last count, it was rejecting one in 20 users (an improvement, at least, on October, when 55% of visitors couldn't complete their enrolment), and in late November the auto-complete on the search bar was suggesting hacking methods rather than showing useful search terms. In fact, as I write, the site is down entirely. At the same time as healthcare.gov spluttered, the new version of Common Application, the software that supports the admissions process at more than 500 US universities, has also had teething problems. Universities were forced to push back deadlines after admission essays were reduced to a "garbled mess" by the system, while other students found that their completed applications were suddenly invalid. The problem lies in the fact that complexity doesn't grow in a linear fashion. One developer working full-time might be able to build a simple site that can handle a million users. Then, as the goals for a project grow, more and more people need to be brought in, because one developer can't do everything. But 100 developers can't do 100 times the work of that solitary programmer, because, as the size of the team grows, more time is spent co-ordinating everything with each other, and less working on the network itself. This idea that you can throw people at a problem has even been given a name – the Mythical Man-Month, coined in a book of the same name written by Frederick Brooks in 1975. The fact that large software projects are much more complex than smaller ones doesn't mean that they are all doomed to failure. For every healthcare.gov, there is a project such as London's Oystercard, delivered with barely a hitch and living up to its promises. But it does mean that the next time a firm proposes combining all of its functions into one database, a bit of scepticism may be warranted. Our editors' picks for the day's top news and commentary delivered to your inbox each morning. |