Skip to content

Making software like intensive care or bombing missions

Today Ben Simo twittered a link to Cem Kaner‘s keynote slides from CAST 2008 on The Value of Checklists and the Danger of Scripts. This was timely for me because I’d been trying to describe to a friend about why I thought manually executed scripts are worse than useless.

Even better, at least for general inspiration, Kaner’s slides included a reference on using checklists in intensive care units, described in this New Yorker article The Checklist. This is a fantastic article and you should go read it now. Go ahead, I’ll wait.

Back? Excellent, wasn’t it?

Ok, for the cheaters who didn’t read the article here’s one example:

In December, 2006, the Keystone Initiative published its findings in a landmark article in The New England Journal of Medicine. Within the first three months of the project, the infection rate in Michigan’s I.C.U.s decreased by sixty-six per cent. The typical I.C.U.—including the ones at Sinai-Grace Hospital—cut its quarterly infection rate to zero. Michigan’s infection rates fell so low that its average I.C.U. outperformed ninety per cent of I.C.U.s nationwide. In the Keystone Initiative’s first eighteen months, the hospitals saved an estimated hundred and seventy-five million dollars in costs and more than fifteen hundred lives. The successes have been sustained for almost four years—all because of a stupid little checklist.

(More in the fine article, which really is worth reading.)

What I found so exciting about that article is it is such a strong evidence that simple simple change in practice can yield wildly improved results, and in an area that is every bit as complex and demanding as creating software.

I had a similar insight this summer while I read The Mundanity of Excellence, an article by Daniel Chambliss. Chambliss studied the difference in performance among swimmers to explain why some excelled and others did not. He found that it didn’t come down to any of the things you might expect: unusual personalities, qualitative differences (doing the same things but faster) or talent. Instead “excellence requires qualitative differentiation“, that is, doing different things. But not exceptionally different things, just habitually different:

… there is no secret; there is only the doing of all those little things, each one done correctly, time and again, until excellence in every detail becomes a firmly ingrained habit, an ordinary part of one’s everyday life.

I love this message! It doesn’t take magic, it doesn’t take a miracle. It takes decision and discipline and will and learning something new and putting it into practice. This is why I love agile coaching, and teaching engineers TDD and refactoring, and product managers how to use cases and personas, and all those other simple practices that are now considered part of the agile/lean toolkit.

And why it is thrilling to come across an article like this one in the New Yorker that offer a new analogy: the B-17 phase.

Substantially more complex than previous aircraft, the new plane required the pilot to attend to the four engines, a retractable landing gear, new wing flaps, electric trim tabs that needed adjustment to maintain control at different airspeeds, and constant-speed propellers whose pitch had to be regulated with hydraulic controls, among other features. … The Boeing model was deemed, as a newspaper put it, “too much airplane for one man to fly.” … Medicine today has entered its B-17 phase. … I.C.U. life support has become too much medicine for one person to fly.

Airplanes haven’t become more complex since them. Instead the belief of what is needed to pilot them has moved beyond the heroic “Right Stuff” to a sort routine mundane excellence. ICUs are doing the same. I’m ready to join them.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*