Recommended article on checklists

I highly recommend the New Yorker article "The Checklist" by Atul Gawande. (I considered requiring it, but decided for this term just to recommend it.)

Why would I ask you to read a paper about use of checklists by doctors and nurses in hospitals? Because the basic principles here (and even the practice of using checklists) apply also to software development. Creative, problem-solving tasks take a lot of our mental energy. Organizing the routine work and having well-defined steps that we follow in a set order helps us to avoid simple mental slips, and actually help us focus better on the not-so-routine aspects of work. Even so, professionals often chafe at checklists and other ways of organizing their routines.

Returning to my mantra that everything in software development is design: The problem being addressed here is that people are actually very bad at minding a lot of details. In fact, when we're "on autopilot" we tend not to even remember what parts of our routine we have and have not completed. It's both a strength and a limitation of the way our minds work, and we have to design our work methods accordingly. Making some things even more routine, with defined methods and even checklists, helps us make sure we're doing the routine stuff right, and makes sure at least a little attention passes over each of the things we ought to be paying attention to. Supporting the routinization of those parts of the work relieves some distraction from the hard, creative parts we want and need to focus on.

A common use of checklists is in code and design reviews. They can serve as a feedback mechanism, across as well as within projects: If we keep good records of problems that are found in a project (bugs, poorly defined requirements, whatever), we can mine those records to identify the points at which they might have been prevented or detected earlier and more cheaply. We put those on checklists, and work through the checklists at the appropriate points in future projects. These can be simple code organization rules like "Keep configuration constants together in a separate source file" or "use only relative file paths except in a single top-level configuration file". They can also apply in requirements elicitation, specification, and early design stages. For example, a good routine for checking that a requirement is well-defined is to require one or more test cases to be defined as part of the requirement.