It is week 2 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 1 builds the case that the world we live in and the work that we do is very complex.  Complexity creates the possibility for errors, and checklists are a tool to help avoid error in complicated and complex environments.

Chapter 1: The Problem With Extreme Complexity

For those who have taken the time to read Atul Gawande’s biography, Dr. Gawande comes by the medical examples used in the book honestly: by observation and being part of the process.  The depth of the examples in The Checklist Manifesto show just how complicated and complex the practice of medicine has become. The chapter starts by laying out how a young girl was saved after drowning in a partially frozen lake.  The example shows not only what is possible but why this amazing event is uncommon due to the complexity of the interactions between people, methods, and systems. Dr. Gawande goes on to explore the complex interactions required to deliver critical care.  In medicine (and software development), one of most common methods for dealing with the complexity of problems is specialization. Specialization, to an extent, helps, therefore, the knee-jerk reaction is to move from specialization to super-specialization.  Unfortunately, specialization and super-specialization induce a false sense of control and actually generate more complexity. I would liken specialization to creating local optimums while moving the whole system away from an optimum performance. The development, enhancement, and maintenance of software might not be quite as complicated, complex, and fraught with the potential for loss of human life as medicine (at least for in same intimate fashion), but it is not too far off.  I recognize that this type of statement reflects a bit of hubris.

An idea that kept me company during a flight to Atlanta was that the combination of complexity and being complicated at the same time without structure the means the outcome is potentially random. How true!  However, the chapter glances off the difference between complexity and complicated. The operational definition of complexity (from our essay Complexity and Complicated Are Different) that I have found useful in the systems world is the interaction of components in which the outcome is not perfectly predictable based on the known or measured inputs.  This contrasts with the concept of a complicated system. A complicated system is comprised of one or many parts that might be hard to understand or analyze, but once understood the relationship between input and outcome is predictable. Medicine and software development are both complicated and complex.  Arguably medicine might have more components that are complex. We will return to this distinction as we parse the messages in this book.

A quote that I found thought-provoking was “The degree of difficulty in any one of the steps of substantial. Then you must add the difficulties of orchestrating them in the right sequence, with nothing dropped, leaving some room for improvisation, but not too much.“ (page 18) This is a description of how critical care and emergency units have to react to the myriad problems that cross their thresholds.  It might sound like a conceit, but these words are illustrative of the life of software developers (in the broadest sense) regardless of the framework they are using 

Like medicine, software development in all of its forms has had great success but is littered with failures however that word is defined. Many of the same solutions have been adopted in software development including a focus on expertise and hyper-specialization.  Expertise based hyper-specialization has been at the heart of many solutions. The chapter ends with the question of what do you do when expertise is not enough? The answer is a checklist! 

Bought your copy?  If not use the following link and support the Dr. Gawande and podcast:  The Checklist Manifesto 

Previous Installment:

Week 1 – Approach and Introduction