This site is inspired by the book “The Checklist Manifesto”
by Atul Gawande. It aims to collect checklists that are used to stop bugs and improve the quality of software.
Frequently asked questions
Why are checklists useful?
In the book, ‘The Checklist Manifesto’, Atul Gawande presents evidence from a myriad of industries: aviation, medicine, construction, fine cuisine and investment showing that checklists can dramatically improve outcomes. Some examples:
– venture capitalists who used checklists had returns that were 78.26% higher than investors who followed an ‘intuitive’ approach
– planes almost never crash despite the immense risks involved – pilots are trained to follow checklists at every step in the journey especially when confronted with an emergency like Canadian geese disabling the engines (Hudson river incident)
– surgical teams who followed checklists caused 36% fewer complications and deaths in patients
– construction firms building skyscrapers follow immensely detailed checklists spelling out every step in the process as well as how to handle unexpected problems. As a consequence, building failure is almost non-existent whereas small building firms routinely create issues that plague owners
Gawande argues that checklists are essential for avoiding human error and for handling ‘wicked problems’ – challenges that are beyond the ability of even the most expert among us.
What are the hallmarks of effective checklists?
Checklists help in two ways:
1. stopping people from making stupid mistakes (i.e. don’t forget to unlock your wing tips when you’re about to take off)
2. help individuals perform as effective teams by spelling out crucial points for collaboration (i.e. as a air conditioning engineer, have you discussed your plans with the structural engineer to ensure that you’re not trying to put an AC duct where a pillar needs to go?)
Can checklists really work in software development?
Software development is rarely a routine process. Whilst general principles might apply (e.g. clean coding patterns, test driven development), each feature or bug stands on its own. Coding is an intensely creative endeavour that cannot be easily distilled down to a “do this, do that, rinse and repeat” checklist. On the surface, this would make it seem like checklists have no role in software development. But think about it – would you consider flying or surgery to be entirely automatable? Sure we have robotic surgery devices and auto-pilots but we still have pilots in the cockpit and surgeons in the theatre. If checklists have worked in industries like aviation, medicine, construction and venture capital, what’s to say it wouldn’t work in software development?
Why is it that people don’t like using checklists?
“It somehow feels beneath us to use a checklist, an embarrassment. It runs counter to deeply held beliefs about how the truly great among us – those we aspire to be – handle situations of high stakes and complexity”
The Checklist Manifesto – Atul Gawande
Yet checklists routinely improve quality and reduce errors.
Checklists vs scrum – mutually exclusive?
Scrum emphasises “people over process”. Checklists are obviously very process driven. Does this mean that they conflict with scrum? Apparently not because Jeff Sutherland, a co-creator of Scrum, used a “Scrum Checklist”. Checklists are most powerful when they go beyond robotic instructions of “do this and this and this” and also encourage teams to collaborate more tightly. For example, consider the Safety Culture pull request checklist. One of the items is “Has it had a secondary review from someone familiar with the service or technology if needed?”. This item is all about people – finding someone with expertise to review the code to make sure there are no gotchas left.
How do you figure out how to craft a checklist?
Boeing has a rule of thumb – no more than 5 items should be on a checklist. More than that and people start skipping steps and checklists lose their effectiveness. For that reason, checklists should be kept as concise as possible. We can achieve that in software development by using automation to our advantage. Any step that can be automated, should be automated. The remaining checklist items are things that deliver a high payoff and can only be done by humans (e.g. have you done cross browser testing?).
What are the downsides of checklists?
Checklists which consist only of mindless “do this, do that, rinse and repeat” steps can lure people into a false sense of security. If I do all these steps, then my code will be bug free, right? Not necessarily. No checklist can catch every possible bug. Instead, checklists should strive to solve complex problems by encouraging collaboration between teams. The best way to catch a hard to find bug before it goes out to production is to get the right people to look at the code.