I've been making software for a living since the late 1970s, and I still love it! I love how software can magnify and amplify our thoughts and ideas, the way mechanical engines amplify our actions. I love how software can materialise reality out of nothing but mere thought. I love playing in a space which is limited only by the most fundamental laws of mathematics, and my own imagination.

My first proper job was in the aviation industry, and it was there I developed the skills (and a taste) for reliability and predictability. After all, if an avionics systems crashes, you don’t get to switch it off and switch it on again - you’ve got a hole in the ground. Since then, I’ve plied my trade in all kinds of safety- and mission-critical environments: medical, automotive, marine, even system- and infrastructure level. I've worked at scales from enterprise down to the chip surface, and I've used technologies from the prosaic to the exotic — I routinely use analog computing techniques in GPU and DSP programming, and the photo above is me teaching a course about quantum computers.

I’ve also worked in conventional, more commercial programming teams, and I’ve noticed something. Writing software at scale is really hard! Software is a byword for missed deadlines, blown budgets, and disappointed users. Switching it off and switching it on again is a perfectly acceptable way to keep most systems running. We all shake our heads, sadly, and complain “We can never make it perfect”, and (in the fog and chaos of the software development battle) we all wish there was a better way.

There is a better way. The reason writing software is so hard in-the-large is because we write it so badly in-the-small. It’s true: we can't make software perfect, but we can make it behave perfectly in spite of its own imperfection and the exigencies of its environment. That’s how we can build aircraft and medical instruments and automotive systems and — our crowning glory — the Internet, to which we regularly, unthinkingly entrust our lives.

When you start to write software to this standard, when you leave nowhere for malfunctions to hide, you never have to debug: not during coding, not during review, and certainly not after deployment. And then something interesting happens: your velocity goes up — way up! More than one study has shown that you can get ten times the value — or more — out of your development effort, just by getting it right first time.

In a world in which everything now works (or doesn't) because of the software inside it, don't we owe it to ourselves and to each other to ensure the software is reliable? In a world whose appetite for software is so voracious that we can’t recruit even half the developers we need, isn't it just common sense to use more efficiently (and train more effectively) the developers we do have?

So this is me, and this is why I’m here. I believe deeply in the value of building correct and reliable software, and (after decades of experience in all kinds of development shops) I’m convinced it's a teachable skill. See for yourself! I've written a book about it: Extreme Reliability.

Today, I provide in-person training, hands-on consultancy, and project leadership. Flawless code, faster delivery. How can I help you?