I’ve just finished listening to the audiobook version of The Checklist Manifesto by Atul Gawande. (Book web site at [1] thechecklistmanifesto.com). Overall I think it’s worth reading, especially for those of us in highly technical roles.

Overview

The book outlines Dr. Gawande’s experiences with checklists, and what he’s learned about how they can make the performance of complex tasks more consistently successful. He presents examples from many realms of endeavour, including medicine (he is a medical doctor), architecture/construction, aviation, and finance. In each area he shows how the creation and use of checklists has allowed those who follow them to complete tasks in a more consistently successful manner, while (seemingly paradoxically), allowing for more flexible reactions to unforseen circumstances. Given the apparently obvious benefits of using a checklist, it is surprisingly rare, even when doing so has been proven to be beneficial to colleagues. He discusses what makes a good checklist and describes his experience developing one from scratch.

Comments

I sometimes found that Dr. Gawande’s anecdotes went on a bit long. OK, building a 50 story building is complicated, we get it. Tell us how the checklists help!There are a lot of medical examples (he is a doctor) and I sometimes had to struggle to apply the lessons from the medical checklist stories to my own environment.

What I learned

Simple/Complicated/Complex: Early on in the book Dr. Gawande divides tasks into three levels of difficulty (Note: these are not his divisions… someone else invented them). There are simple tasks, which, once learned, can be executed successfully most of the time. Complicated tasks take longer to learn, but can eventually be codified as well. Complexity arises when there is simply too much variability and randomness to possibly codify everything. (A good summary, with some good reference links: [2] Simple vs. Complicated vs. Complex vs. Chaotic)

Hipocrisy: I’m going to recommend the use of checklists. But that doesn’t mean I’ll consistently use them myself (I will try!). I’m in good company: near the end of the book, he mentions that about 80% of the surgeons and nurses thought they would follow the checklist he had developed. But 93% would want a team operating on them to follow it.

Not Forgetting the stupid stuff. There is a seeming paradox in following a checklist (codified, rigid) in a complex environment that will likely require flexibility and creativity to succeed. The author argues that this is precisely because the checklist helps you to not forget the simple, stupid things that are easily forgotten in the heat of the moment, but which, in their omission, can cause the entire process to fail. My interpretation is that there are at least two reasons for this:

1. Time/Danger pressure. Either time is short, or there is actual danger. This encourages skipping steps.
2. Boredom: We want to get to the interesting stuff. In technical fields, we tend not to want to spend time on the boilerplate, but get right to the guts of the interesting problems. Again, this encourages skipping steps.

How to successfully execute tasks in a complex technical environment. Bringing together the items from the book’s many anecdotes and stories, here are some items that I think apply to the software development arena:

• Communication: In the building industry example, Dr. Gawande points out that there are in fact two checklists. The first is obvious: weld girder A to girder B on such-and-such a date. But the second is more subtle: force people to talk. Primes from each functional area (structure, electrical, building owner) have a defined schedule of communications. Is this task done? How did it go? Were there any problems that other areas need to know about, or that will affect the schedule? This is similar to various notions in Agile design (scrums, involving the customer), but is more well-defined. I’m struggling with exactly how to incorporate this into a software development process, especially given the clear difference between a building plan (which seems like a classic waterfall design: you know up front exactly what you are going to build and when) and an Agile software development project. However, it seems to me there is something of value here.
• Don’t forget the simple steps: In his surgical checklist, administering antibiotics just before an operation is about to commence is a step that makes a large difference in the number of post-operative infections. But the step is quite frequently missed or performed too early. In software development there are simple things that must be done, but are easy to miss. Did you forget to re-throw the exception? Could that pointer be null? Did you deploy the updated library when you deployed the updated mainline code that calls it? I can think of several checklists that I could prepare that would assist me day-to-day.
• Use a checklist: I’m just as guilty of preparing checklists for others but not following them myself. Hopefully, having read this book, I will improve on that.