Book: the checklist manifesto

Engineers needs a checklist, full stop.

Engineers are disciplined, methodic, scientific and follow well-though best practices to to their job. A structural engineer knows what to check to be sure their latest construction will stand 100 years, and they refer to the industry best practices to do so. An automotive engineer exactly know what and how to test things to be sure they will not break under expected conditions and so on and so forth.

However, software "engineers" aren't like that.

We like to all ourselves engineers, but we also like to claim that our endevour is a "creative" one. We follow the latest fads without any scientific approach, or empirical evidence that what it's doing is right, but we also like to think that we do so for safety, or whatever. However, we ignore the simplest of the instruments that can help us be sure that we don't forget stupid things: checklists.

I was reading how the SQLite project does releases,

SQLite verification plan

and while the SQLite project is, looking at the project's structure, one of the most agile organizations ou can think of, they are well-organized, disciplined, and with a release process so good, while being light, the majority of the other open source projects pales in comparison.

And they took inspiration from "The checklist manifesto".

Reading it, don't expect "best practices", don't expect examples or tutorials. The book is a series of terrific tales about projects where the author, among others, tried to apply the simple principle of using a checklist to not forget the most stupid things. Sometimes with success, sometimes not much.

The book is quite linear in this, building up stories from all over the world, you can imagine, while reading it, what the author is talking about and the value a simple tool, such a checklist, provided to doctors, nurses, hedge fund investors (sic!) in carrying out their duties. It finishes with the story of the author almost missing a patient on the surgery table, saved by the readiness of the equipe and the preparation work that was done before the surgery, thanks to the simple act of checking a list.

Things like "overengineering" are a thing, even for a surgeon making a checklist, and the book brillantly tells you to not fall into that trap, by showing you the author's failure of doing so. The book is a journey about how the checklist went from "idea", to "prototype", to "abject failure", in the end to "just right". You see the attempts during the author's path in doing so.

If you are a software engineer, go buy the book and read it. You will understand that simple checklists are perfectly fine in our agile world and they will help us do our job better, with less stress and with less mental burden, in the end.