What is it with technology? We can put men on the moon, but we can’t create an airport baggage system that doesn’t foul up. Or a word processor that doesn’t crash. Or a web application with a consistent user interface.
One explanation could be that there are actually two sources of difficulty in most human endeavours: necessary difficulties, where a task is at the limit of or beyond a person’s capability, and accidental difficulties, where a task is perfectly achievable but we are open to simple human errors. Though the progress of technology, training and specialisation has raised the absolute limits of what is achievable in most disciplines, human error remains stubbornly as a fact of life and little has been done to ameliorate it.
This is an idea that is explored at length in The Checklist Manifesto. The author, Atul Gawande, is a surgeon who became suspicious of the number of failures that were happening in surgery that are attributable to human error, often at the cost of grievous injury and death. It would be funny if it wasn’t tragic, that no amount of training (and surgeons are extraordinarily well-trained) is enough to stop a surgeon cutting off the wrong limb, or forgetting to administer vital drugs.
Gawande pioneered a remarkably simple solution to this in the form of a pre-surgery checklist. The evidence is that this reduces complications by double-digit percentages. The main problem in implementing it seems to be in persuading alpha-male surgeons to admit that they are fallible, and that something as simple as a 30-second checklist can make a difference.
It’s not just surgery either. Gawande gives examples of checklists being successfully applied to contain human error in other fields such as finance and, of course, air flight. As a software developer, the following commentary caught my eye:
Tom Wolfe’s The Right Stuff tells the story of our first astronauts and charts the demise of the maverick, Chuck Yeager test pilot culture of the 1950s. It was a culture defined by how unbelievably dangerous the job was. Test pilots strapped themselves into machines of barely controlled power and complexity, and a quarter of them were killed on the job. The pilots had to have focus, daring, wits, and an ability to improvise—the right stuff. But as knowledge of how to control the risks of flying accumulated—as checklists and flight simulators became more prevalent and sophisticated—the danger diminished, values of safety and conscientiousness prevailed, and the rock star status of the test pilots was gone.
As a discipline, software is remarkable for the speed at which it has developed from being on the bleeding edge of research to being an integrated part of our lives, and this is something that the well-worn analogies between software engineering and civil engineering inevitably fail to model. I’ve often wondered whether this rapid growth, and the small number of generations between the bleeding edge and the current state of the art have distorted our view of what good software engineering should be. This is an idea explored in more detail, and specifically about software, in The Inmates are Running the Asylum, a book I encourage all developers to read.
So, how applicable are the solutions in The Checklist Manifesto to software development? That’s where it gets difficult. Much as I’d like to see the discipline mature, the opportunities for checklists per se are small. There are certainly opportunities to ensure best practices in things like code reviews, merging to release branches or building installers. But ideally any purely repetitive task should be automated anyway, and this covers a lot of ground: software development differs from surgery in that while surgery only looks repetitive, software behaviour genuinely is deterministic. Automated tests, continuous integration and 1-click installer builds are probably the closest thing we have to the surgery checklist, and they are already best practices (though like the surgery checklist, often ignored by alpha males who think they know better).
I’m going to continue investigating the checklist idea and see whether I can integrate any of the spirit of it into my work; I’ll update here if I have any noteworthy progress. But it would be remiss of me not to emphasise one very important point: this isn’t about taking away the creativity of the job, it’s about minimising the cognitive load of routine tasks so that tasks requiring creativity and judgment can be given more effort, not less. There is an art to writing a good checklist, and much of it is in minimising the checklist to give it maximum impact with minimal weight.
If software engineering could become more like flying, perhaps it would be no bad thing. Being a pilot is still a highly technical job that requires great experience and commands great respect. The skill of the pilot is indispensible when something unexpected happens, but that doesn’t mean they carry out routine takeoffs and landings by the seat of their pants.