Early Ideas about Using Checklists in Software Engineering

Some months ago, I wrote a review of Atul Gawande’s Checklist Manifesto and about using checklists in software development.

I’m pleased to say that it looks like I might get a chance to follow-up on that idea more in the coming year. I’ll keep you updated. In the meantime, here are few ideas on the subject from one of my notebooks. (I appear to be going through these “historical documents” in a rather random chronological order.)

When are the pause points where we might use checklists?

  • Before starting to design
  • Before starting to code
  • Before code review
  • Before submitting changed files
  • Before QE-led testing

Who might be included in the check-off activities? The goal is to catch problems and communicate what’s happening.

  • Coder/Developer
  • Quality Engineer/Tester
  • Buildmasters
  • Doc Writer
  • Project Leader (?)

What’s so mindless that it’s taken for granted? (e.g., “build and run tests on every platform.”) Are these second nature? Or are they sometimes forgotten/overlooked/not done?

What goes onto a “pre-flight” checklist? What goes onto special circumstance (“OMG the plane is crashing!”) checklists? The idea is to have lots of small checklists.

What level of specificity is required for a checklist?

This entry was posted in From the Yellow Notepad, Hoarding, Life Lessons, Software Engineering. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>