In 2011, Atul Gawande published The Checklist Manifesto: How to Get Things Right. I first became aware of it when I had the opportunity to hear him speak during his book tour for his latest book, Being Mortal, at the end of 2014, but only got around to reading it this week. The book is about managing complexity in the medical field, but can also be applied to software development.
The central thesis of the book is that modern knowledge has made the world too complex for humans to handle unaided. Take any complex profession – medicine, architecture, etc – and you find specialization and sub-specialization: there’s simply too much expertise required for anyone to be a generalist. Even within the sub-specialties, there’s so much to keep track of that it’s easy to miss a step, and that one missed step can result in a collapsed building, crashed airplane, or dead patient. We have finally advanced enough that “errors of ignorance” – mistakes because of what we don’t know – are often less important than “errors of ineptitude” – mistakes from not making proper use of what we know.
The solution is the simple checklist: a written list of the steps to take each time an action (whether it’s landing a plane or checking a patient) is performed. Interestingly enough, the checklists aren’t useful only for those who are new to an area, but even for experts with many years of training and experience who may nonetheless overlook a minor, routine step under stress.
So how can we apply this to software development? I personally use a checklist (in the form of a spreadsheet) that I compare against every new activity my team creates. The list contains around a hundred items to check, from making sure that CSS files are linked in the correct order to ensuring that our naming conventions are followed and strings are properly internationalized. It’s a lot of minor details, the vast majority of which we can expect to do correctly on any given day without the aid of the checklist, but I find that I usually catch a few things in each new activity. Unlike the steps on a doctor’s checklist, these aren’t going to kill anybody if they’re missed – most of them will simply result in a slight inconvenience to us (the developers) in the future – but running through the checklist before the end users ever see the software lets us fix the issues more easily and makes the software look more polished to end users (and testers) as we find issues before anyone sees the results.
Of course, we can also look at non-technical checklists: does the code do what it’s supposed to do, regardless of the implementation? To some extent this is what we’re doing when we write unit tests: we define what each unit should do, and then check that it actually does what we expect. I find that one of the best ways to avoid getting a lot of change requests is to have a checklist of exactly how the finished activity should work, and verify that it meets every one of the requirements (many of which might be too simple to remember when coding) before marking the development as complete.
What processes do you use for finding bugs in code? Can they become a checklist?