Last night, I went to a Gresham College lecture at the Museum of London, “How Can Software Be So Hard?” presented by Professor Martyn Thomas CBE. The lecture itself was great – good content supported by solid examples. I must say there wasn’t a great deal there that I haven’t heard before – software engineering is an immature discipline; we rely too heavily on “testing” to validate and verify the systems we create; validation normally happens far too late to do anything about the problems it uncover; we’re overly reliant on modules and components that we can’t actually trust to work properly… all interesting and valid observations, but nothing particularly revolutionary.
Personally, I think the question posed in the lecture title is, to some extent, built on a false premise. Towards the end, he makes the observation – whilst talking about teenagers getting rich by writing iPhone games – that we only focus on the success stories, and the countless failures don’t get any attention. Which is true – but I think with software, we routinely take so much success for granted that it’s the failures which stand out. Sure, they happen – but if you think software is hard, try building a mechanical or an analog system that can send high-fidelity music from Boston to Singapore, or show the same colour photograph to a million people five minutes after it was taken. So many software projects are instigated to pursue efficiencies – to take some business process or system that used to require tens of thousands of people, and hire a few dozen programmers to replace it with a system that basically runs itself; it is any wonder it doesn’t always go smoothly? There’s a lot of things which are easy in software and close to impossible in any other domain, and I think to lose sight of that would be disadvantageous in an age where we’re trying to inspire more kids to study STEM subjects and pursue careers in science and engineering.
The thing that really stuck in my head, though, was a comment Professor Thomas made in response to a question after the lecture. Somebody asked him what he thought about self-driving cars, and amongst the points he raised in response, he said something like:
What about pedestrians? Why would you find a crossing, press the button and wait for the green man if you know all the cars on the road are programmed not to run you over?
Over the last few years, I’ve spent a lot of time studying the way smart devices are affecting the way we interact with the world around us – something I’ve covered at length in my talk “Are Smart Systems Making Us Stupid?”, which I presented at BuildStuff last year. I’ve looked into all sorts of models of human/machine interaction, but I’d never considered that particular angle before – and it’s fascinating.
Our basic instinct for self-preservation is reinforced from an early age – is there anybody here who DOESN’T remember being taught how to cross the street? So what happens to those behaviour patterns in a world where kids work out pretty early on that they can jump in front of Google Cars and get away with it? Do we program the cars to hit a kid once in a while – not to kill them, just give ‘em a nasty bump to teach them a lesson? How much use is a self-driving car when your journey takes longer than walking because your car slams the brakes on every time a pedestrian walks in front of it? Maybe you’re better off dumping your luggage, or your shopping, in the car, and taking the train instead?
It’s also an interesting perspective on a discussion that, until now, has been framed very much from the perspective of the driver – “will my self-driving car kill me to save a dozen schoolkids?” – and raises even more questions around the social implications of technology like driverless cars.
The next talk in the series is “Computers, People and the Real World” on April 5th, and if you’re interested in how our increasing dependency on machines and software is affecting the world we live in and the lives we live, I’d heartily recommend it.
(PS: if anyone from Gresham College is reading this – get somebody to introduce your speakers. They’ve worked hard to prepare the material they’re presenting; help them make the best possible first impression by taking the stage to a round of applause from a crowd who already know who they are. It’s not that hard, and it makes a huge difference.)