Using Checklists for Software Development

In another post I wrote about checklists in aviation and in medical practice. I work in software development, and I’m curious about how checklists might improve my work and that of my colleagues.

Paul Eie has an interesting post on the subject, from back in 2011. He points out two kinds of checklists, “Read-Do” and “Do-Confirm” checklists. Thinking back to when I was trained to fly little airplanes, it was drilled into me that aviation checklists are “Read-Do” checklists. My instructor warned me and the other flyboy wannabees against trying to do the steps from memory, and then using the checklist to confirm we had done them. He said that practice made it too easy to skip steps by mistake.  He said that the point of the checklist is to slow you down and get you to focus, if only for a moment, on each task you have to do.

Mr. Eie’s post also points out that checklist should have a single well-defined purpose. As examples he mentions setting up a software development environment, and tracking down a software defect.

There are tons of checklists available online to help software people prove they followed particular development methodologies. Some of these have dozens of steps, many of which require creating and then inspecting some sort of document.  Those are fine, but they’re about enforcement.

What checklists can you and I use as software developers? I do a couple of things already. For example, when I’m checking finished work into source control, I do these things:

• Is the code free from unexpected warnings (yellow bars in VS)?
• Does it work?
• Rebuild it from scratch.
• Does it work?
• Does the ticket describe it correctly?
• Does the ticket explain how to test it?
• Using the source control system, make sure no unexpected modules will be checked in.
• Using the source control system, inspect the differences.
• Does the checkin comment mention the ticket number?
• Did the checkin complete without errors?

I have been trying to get this procedure to be second nature. But, I’ve been doing this for several decades, and I still skip steps. In that respect, I’m like the doctors in Gawande’s hospital who forget to wash their hands. So, I’m going to use a checklist.

Now, we software developers have a big temptation. It’s the temptation to automate procedures. Truth be told, there’s nothing wrong with automating procedures. There’s nothing wrong with top-notch tools that can do the routine stuff the same way every time. That’s why I use Resharper for C# code and Eclipse’s code inspection features for Java code. That’s why I use the IDE tools that redo the indentation after I change the logic in a method.

But when we try to reduce a checklist to just one step by, somehow, automating the steps, we deceive ourselves. We trick ourselves into thinking we’re just too smart to have to spend a little time focusing on each step. I can’t count the number of times that skipping a step has caused me to waste hours trying to sort out a problem.

If you read this, I hope you’ll put in a comment describing your checklist process, and what you’ve found effective.