This morning, I have been thinking about a recent flight I took in a small plane — the type that carries about 20 passengers. Right before takeoff, I noticed the captain with a clipboard in hand, working his way through a checklist. To be honest, I felt safer that he was checking everything on the plane. It also reminded me that I still rely on checklists all the time, even for developing software.
Although my software team tries to automate as much as possible, there are still times during major releases that we need to communicate with other parts of the company and make judgment calls as to whether or not we need to proceed or roll back. I have found no matter how strong or experienced the team members, or how good the automation tools, I am not confident we will execute unless we plan carefully and create an old-fashioned checklist with a person responsible for it.
Recently, we re-branded our main Web site with a team that was relatively new. There were many places for us to mess up. So, to lessen the risk, we set up a Google Doc with our release plan and moved items from red to green as they were done. No clipboard this time, but the process was essentially the same.
Create old-fashioned checklists with a person responsible for it
I recently became more of a list zealot after reading Atul Gawande’s Checklist Manifesto, a 2011 book that describes the benefits of using lists to improve the survival rates of patients in hospitals. In turns out that even the best-trained surgeons occasionally skipped important steps during surgery. They also forgot to clean their hands sometimes. Hospitals addressed the problem by requiring surgeons and nurses to use simple lists of tasks to complete during surgery. As a result, lives were saved.
The book also describes how the airplane industry struggled with errors in the 1930s until the adoption of “pre-flight checklists” reduced accidents. This practice, as I found out in that small airplane, is still in place today for commercial flight.
I have also found quality control checklists helpful for projects. When I struggled with writing as a kid, my father would often bring out Strunk’s Elements of Style to help me with editing. “Principle 13: Omit Needless Words” still rings in my ears. For software development, Joel Spolsky created a popular 12-item list for engineering teams, entitled the The Joel Test, that is as helpful today as it was when he first published it in August, 2000.
Quality Control Checklists are helpful for projects
I have used these sort of checklists myself. A few years ago, when I worked in a consulting division of a software company, I frequently took over half-finished client projects, and found it useful to create a list of things to check: Do database transactions have proper rollback logic in case of error? Are there timeouts for every external connection? Do applications re-start after a power outage? Are primary keys created in a thread-safe manner? Do the logs roll, and are they available for review in case of a problem? I frequently found that sophisticated projects had very basic errors due to oversight or turnover in personnel. A checklist allowed me to fix applications systematically.
Well, my coffee is done and I need to start my day. As usual, I will begin by creating a list …