Checklists

What flying a B-17 bomber can teach us about software development.

Checklists

Have you ever tried to write down the names of all 50 states in the US?

Even if you know all 50 states (as most Americans do), recalling all 50 is deceptively difficult.  The first 40 are easy.  The next five take a bit more time.  By the time you get to 49, most people spend several minutes staring at the list trying to remember which one they've left out.  

And that's why pilots use checklists.

Origin of the Checklist

In Code That Fits in Your Head, Mark Seemann devotes an entire chapter to using checklists.  

Here's an excerpt from the chapter introduction:

[C]onsider the origins of the checklist. According to Atul Gawande it started in 1935 with the B-17 bomber.  Compared to previous airplanes, the B-17 was much more complex.  In fact, it was so complex that it crashed on a demonstration flight for potential army buyers, killing two crew members, including the pilot.

An investigation into the crash concluded that it was due to 'pilot error'.  Given that the pilot was one of the army air corps' most experienced test pilots, this could hardly be written off as lack of training.  As one newspaper put it, the plane was just "too much airplane for one man to fly."

A group of test pilots came up with a solution: a checklist of simple actions to perform during take-off, and another to follow during landing.

Checklists are a Memory Aid

A useful checklist does not need to be a step-by-step tutorial.

The importance of each step is simply to remind you not to forget it.  Take our 50 states example from above.  If instead of a blank sheet of paper you had a sheet with 50 lines and the two-letter postal code abbreviation of each state, the task would be much simpler.

In fact, including too much text with each step could reduce the signal to noise ratio making the checklist less effective.

Keeping Track of Completed Steps

Seemann believes that checklists should not be used to "monitor or audit."  

For this reason, he prefers checklists "that specifically don't leave any audit trail.  These could simply be lists on a wall poster, a clipboard, in a ring binder, or similar."  I don't have strong feelings either way on whether you should use a checklist for auditing purposes.  I think that largely depends on the situation.

However, one of the most important reasons to use a checklist is to keep track of which steps have been completed.  

You can't do that with a poster on the wall.  You also can't do that with a wiki or many other common forms of electronic documentation.  Unless you print the article, you have no way of marking which steps have been done.  

Common Checklists

Here are a few examples of Microsoft Access development situations that could benefit from a checklist:

  • Setting up a new application
  • Deploying new versions of an application
  • Defining a database table
  • Configuring version control

The best candidates are processes that you do regularly, but not necessarily frequently.  They also are ones that tend to have many steps that must be completed or many settings/characteristics that you want to verify.

Conclusion

A checklist serves two main purposes:

  1. Eliminate the need to memorize every step
  2. Provide a method to keep track of which steps have been completed

The key to getting good value from maintaining checklists is that you (and your team) need to actually, you know, USE the checklists.  Don't let perfect be the enemy of good.

An imperfect checklist that gets used is better than a perfect checklist gathering dust.

Image by Mohamed Hassan from Pixabay

All original code samples by Mike Wolfe are licensed under CC BY 4.0