Friday, September 25, 2009

Positive Deviance

Surgeons following the trauma logs began to see, for example, a dismayingly high incidence of blinding injuries. Soldiers had been directed to wear eye protection,but they evidently found the issued goggles too ugly. As one soldier put it, "They look like something a Florida senior citizen would wear." So the military bowed to fashion and switched to cooler-looking Wiley-brand ballistic eyewear. The rate of eye injuries decrease markedly.
--- Better: A Surgeon's Notes on Performance, Atul Gawande, p. 64

Not too many books laden with statistics and medical terminology are too compelling to put down for dinner. Better: A Surgeon's Notes on Performance, by Atul Gawande, discusses the reaches and limits of medical performance -- including the very human limitations of doctors and their abilities to make good decisions. How do doctors improve outcomes for patients? An endless array of tiny choices accrue to make good medical practice a demanding art.

This book is a worthwhile read, not just because it is a quick but engrossing book. The dilemmas of how to measure and improve the performance of the practice of medicine are relevant to the headlines we see each day about heath care reform. And the truth is, doctors' performance, like most other human performances, are spread out roughly along a bell curve. Much as we'd like to believe that our doctors are, like the children in Lake Woebegone, all above average, they are not. Even as overall medical outcomes improve, this characteristic of the system holds true. Gawande's concern is to illuminate the ways in which doctors can encourage the best outcomes and thus improve their performance.

Don Berwick believes that the subtleties of high-performance medical practice can be identified and learned. But the lessons are hidden because no one knows who the high performers really are. Only if we know the results from all can we identify the positive deviants and learn from them. If we are genuinely curious about how the best achieve their results, Berwick believes, then the ideas will spread. The test of Berwick's theory is now under way. In December 2006, the Cystic Fibrosis Foundation succeeded in persuading its centers to make public their individual results ...
-- p. 226

Gawande gives advice to medical students about how to put themselves in the best position to become those positive deviants:
  1. Ask unscripted questions. Don't treat your patients or your colleagues like cogs in the machine, look for what makes each one unique.
  2. Don't complain. It drags down the morale of the team, and wears away the belief that improvement is possible.
  3. Count something. Approach the world around you through the eyes of a scientist. "If you count something you find interesting," he writes, "you will learn something interesting."
  4. Write something. Communicate. Add your observations to the world.
  5. Change. Recognize the inadequacies in what you do and be willing to try something new.
The work of a software engineer, unlike a doctor, very rarely puts a human life in the balance. The risks and responsibilities we have in society are very different. Still we have the challenge of knowing how we are doing and if we are doing the best job that we can. Attempting to become positive deviants is not a bad place to start.



Thursday, September 17, 2009

Getting Started

If you're at IMVU, the day 1 goal for a newly hired developer is to turn the crank through the entire build and release process, getting a bug fix into deployed software. (This is not a post about continuous deployment, although that's a fascinating topic in and of itself. And for those who are skeptical that such a process can coexist with a useful or valuable product, there's always Flickr.)

In organizations I have experience with, time-to-first-deployed-bug-fix is not a useful way to look at ramping up developers within the organization. Deployment is a rare event. Even if it's every three months that's rare compared to the checkout-build-bugfix-test-checkin cycle that forms the meat of the development cycle.

In organizations that don't practice continuous deployment, time to first bug fix check-in is a similar way of measuring one element of ramping up -- how long it takes a developer to be able to turn the crank for one revolution of the process. I've seen it take a day in organizations that had a well defined build process, to over a week for a product with a hairy complicated and mostly manual install that took a lot of training -- and much longer, several weeks even, in organizations that are scared to touch their code.

I'm particularly thinking about this because I'm about to be the New Guy, starting work at a new company. How long will it take me to file the first bug or write the first test? What will that tell me about the team and technology I'm going to immerse myself in?