In the 1950s and 1960s, when we first started writing software at industrial scale (and “computer” was a job, not a machine), programming was really hard! It was slow, error-prone, and demanded complex rituals and incantations to make anything work. Back then, software was a byword for missed deadlines, blown budgets, and machines going haywire. In short, software was a mess.

Seventy years on, we now have new programming tools (mostly: languages), new programming paradigms (mostly: objects), and new programming methodologies (mostly: agile). And yet, programming is still really hard, our software systems are still a mess - albeit a rather bigger mess than in the past - and we’ve given up even trying to budget large developments.

Why is programming so difficult? In contrast to nearly every other engineering discipline (which routinely use self-stability, failsafety, and feedback to build robust and resilient systems) software amplifies disturbances, and so builds systems which are inherently brittle. It doesn’t matter how carefully we error-check results or how assiduously we null-check our pointers, sooner or later a disturbance will start a crack in the code, which will spread to the whole system.

And yet, when it comes to it, we can create software so good we can entrust our lives to it. Aircraft, medical instruments, even the internet all work pretty much perfectly pretty much all the time. The programmers who create these exquisite systems: what do they do that the rest of us don't? What can we learn from them?

In this talk, Jules explains the fundamental difference between software and other kinds of engineering, will explore some of the things we do to strengthen our code which (in fact) make matters worse, and will introduce a paradigm for creating code which is robust and reliable even in the presence of errors. He shows that it takes less time, costs less money, and dramatically improves your system’s security to build highly-reliable software than it does to build the buggy variety.