When code kills: are we headed for a software apocalypse?
The world is running on software. Critical systems that were once controlled mechanically now depend on code. And if that software goes wrong… then what?
Anyone that’s ever tried to navigate a busy crossroad with broken traffic lights knows how a simple failure can result in absolute chaos.
As software continues to absorb more and more of the world, we explore what makes software fail, and what it could mean for the future. Are we heading for a software apocalypse?
Software is eating the world
As Marc Andreessen famously put it, ‘software is eating the world’. The pervasive nature of technology — particularly software — means that we’re seeing it spread into every aspect of our lives.
Software is in our cars, homes, offices, and pockets. Software has eaten photography, finance, entertainment, reading, music, video. It’s tucking into driving, deliveries, and energy. It’s keeping our emergency services running, and operating hospital machinery.
It’s everywhere, no matter the business model, or the importance of the system in question. The term ‘tech industry’ has become meaningless. And, with the coming applications of AI, IoT, and 5G, the all-encompassing software spread is showing no signs of slowing.
Signs of the times
Cybercriminals have demonstrated just how devastating it is when software becomes unavailable to us. Take, for instance, the WannaCry ransomware attack that shut down the NHS. Or, more recently, the $600,000 ransom paid by Florida to get their systems back up and running.
The same thing happens when the software fails all on its own — and it does fail. In fact, software failures have left emergency services unreachable more than once. The most recent example comes from the Netherlands. Telecommunications network KPN went down, knocking out their 112-emergency number for four hours.
Another example comes from America where, in 2014, a software failure resulted in no 911 calls. The outage lasted six hours and affected 11 million Americans.
What if, then, these failures all happen at the same time?
Herein lies the possibility of a software apocalypse. That is, what would happen should these systems fail en masse.
Say, for instance, software within an IoT system fails. That failure then creates a domino effect that impacts everything else on the network. Suddenly, nothing is working. No emergency services. No cars, no hospital machinery.
The result is apocalyptic chaos. All while programmers scramble through billions of lines of complex code to find and fix the point of failure.
Why software fails
Whether the software apocalypse is on its way or not hinges on whether crucial software fails in some way. That means that if the code is good, disaster is averted, right? Except, that’s not why software fails.
Software doesn’t ‘break’ like the machinery before it did. When software goes wrong, the point of failure isn’t because a specific line of code ‘wore out’. Instead, the point of failure lies further back. That is, in the way the software was built to begin with.
Software does what it’s told to do — regardless of whether that’ll give the outcome you want or not. When software fails, then, it’s down to a failure in foresight or understanding, not a failure of the tool itself. And it’s the complexity and invisibility of code that impedes foresight and understanding.
Code cloak of invisibility
With a physical machine, you can see when a part is worn down and in need of maintenance. You also see exactly what happens when you replace or change the parts. This is less obvious with code.
Code has enabled all these critical systems to become complex. Yet the work behind these changes is invisible. The physical tools appear in much the same way as before. You can’t see the millions of lines of code that go into it.
When things go wrong, you must wade through all that code. And even the most adept programmers will struggle to make sense of thousands of lines of code several months or years down the line. Code buries the issues and obscures the fix. You can’t see the problem right away, and you can’t see the direct result of your code tweaks in real time. It’s all invisible.
Rethinking our code approach
Avoiding the software apocalypse, then, could mean getting closer to the problem from the start. That is, by creating a way to improve the visibility of problems and fixes for anyone — whether they can code or not.
For instance, with a ‘what you see is what you get’ (WYSIWYG or ‘Wizzywig’) interface, as proposed by Bret Victor. This would mean a user interface that allows people to manipulate the code, and immediately see the effect it would have on the software. All without in-depth coding knowledge.
In general, avoiding a software apocalypse means improving the ways we communicate with computers. For instance, by allowing humans to work with natural language, models and drawings. All of which the computer understands and turns into code. This would, in turn, mean the complexity of code couldn’t impede our ability to make software work again if it fails.
Software has come to form major linchpins in the world. When it fails, it can create a ripple-effect of disruption, danger and even – in a worst-case scenario – disaster on an apocalyptic scale.
This doesn’t mean we should revert to the dark ages and do away with our substantial technological progress. Rather, the way we approach code needs to change. In a world increasingly reliant on code, the practice itself should not remain as a handicraft. Not only is it not economical to run the planet based on billions of lines of hand-written code, it’s not safe.
So, the most forward-thinking software developers may soon be developing themselves out of a job. To avoid an apocalyptic future, we need to start coding tools that remove the need to code.