« November 2007 | Main | January 2008 »

December 30, 2007

New Car

Hey, we bought a new car over the holidays. To figure out which one we bought, you probably only need to know two things about me:

  1. I have four children.
  2. I grew up in Canada, with attendant liberal guilt.

The car is nice; it has all kinds of doodaddery like syncing with my phone via Bluetooth, keyless entry/start, and automatic headlights. Of course it has some annoying software features, in how it deals with lights left on after the engine is turned off, how the radio controls work, and so on. This is the sort of thing where Microsoft would probably make it a configuration option and throw it into the hands of the user. Car manufacturers instead make a choice, I guess based on thinking what would satisfy the most users. Maybe they walk through scenarios like we do and match the design to the requirements that emerge, but I'm still baffled by some of the choices (the most obvious one is supporting the "the reason they left their interior lights on is because they want to drain their battery" scenario which most cars seem to nail, but there's also the "I don't see why somebody would want to be able to see the name of the song that is playing AND have access to their presets on the same screen" decision, some thinking about preventing carjacking during remote engine starts where I don't quite see what situation they were concerned about, and a few other minor ones). Still those are nitpicks, and the car has no more design choices I disagree with than any other recent car I've owner (my first car was a Honda Civic that was so basic that every control was the end result of decades of refinement, so there was nothing I didn't like).

There has been this rumor floating around the Internet that the little gas pump icon on your dashboard indicates, via the side that the nozzle is on, which side of the car your tank is filled from. This is the report from our three cars:

  • My old car: icon nozzle is on the right, tank is on the right.
  • My new car: icon nozzle is on the right, tank is on the left--but next to the icon is an arrow pointing left.
  • The minivan: icon nozzle is on the right, tank is on the left.

So it looks like the rumor is bogus--based on my evidence, it's more likely that the icon nozzle is ALWAYS on the right, and your dashboard may or may not have some way to tell you which side the tank is filled from.

Posted by AdamBa at 10:52 AM | Comments (1) | TrackBack

December 16, 2007


Atul Gawande had a fascinating article about how using checklists in intensive care can save lives. There are a lot of steps involved in caring for someone in critical condition, and a single mistake can be fatal. A few years ago a doctor named Peter Pronovost decided to put together a checklists of steps to follow when inserting a "line" (a thin plastic hose, used for draining various fluids) into a patient. The goal was to avoid infections where the lines were inserted. It turns out there were just 5 simple steps, but after nurses in his I.C.U. starting using the checklists, they realized that they missed a step with over a third of patients. After using the checklists for a year, the line infection rate dropped from eleven percent to zero. Just in that one hospital, the checklist had saved eight deaths and two million dollars.

Pronovost created checklists for other procedures, with similarly amazing results. He had some success in some hospitals in Michigan, saving an estimated $175 million and 1500 lives in 18 months. But when he tried to get other hospitals to adopt the idea of checklists, he met resistance. From the article: "We have the means to make some of the most complex and dangerous work we do—in surgery, emergency care, and I.C.U. medicine—more effective than we ever thought possible. But the prospect pushes against the traditional culture of medicine, with its central belief that in situations of high risk and complexity what you want is a kind of expert audacity—the right stuff, again. Checklists and standard operating procedures feel like exactly the opposite, and that’s what rankles many people."

The article continues: "The still limited response to Pronovost’s work may be easy to explain, but it is hard to justify. If someone found a new drug that could wipe out infections with anything remotely like the effectiveness of Pronovost’s lists, there would be television ads with Robert Jarvik extolling its virtues, detail men offering free lunches to get doctors to make it part of their practice, government programs to research it, and competitors jumping in to make a newer, better version."

This is another area where you can establish an analogy between medicine and software development. Gawande talks about how early airplane test pilots believed you needed the "right stuff", a mix of daring and courage, but how eventually it became more important to focus on safety, and things like checklists and flight simulator time became more important. He feels medicine is still somewhat stuck in the "right stuff" mode, and I think that software development is also stuck there.

At Microsoft there actually is a checklist site, containing lists of things to check during spec reviews, code checkins, and so on (it's at http://checklists, under the EEG section, if you're inside the steel shade). Compared to a medical checklist, which is based on years of experience and is very specific, our checklists are weak; they're based on whatever one person came up with one day and have vague, unactionable items such as "Make sure the design is as simple as possible". But thinking about the medical checklists, which are full of things that "everyone knows", I think ours could still be helpful.

See, it turns out that the medical checklists that Pronovost came up with had two main benefits: "First, they helped with memory recall, especially with mundane matters that are easily overlooked in patients undergoing more drastic events. (When you’re worrying about what treatment to give a woman who won’t stop seizing, it’s hard to remember to make sure that the head of her bed is in the right position.) A second effect was to make explicit the minimum, expected steps in complex processes. Pronovost was surprised to discover how often even experienced personnel failed to grasp the importance of certain precautions." The minimum steps notion is especially relevant to software development. It's amazing how many experienced software developers feel that unit tests are not really that important. The reason is because unit tests feel boring and mundane -- sort of like items on a checklist would feel for doctors. In fact Pronovost points out that it's often nurses who are checking the checklists, and that one benefit is that the checklists give the nurses an excuse to speak up if a doctor misses a step. A software checklist might be vague, but I bet lots of experienced developers don't even consider their work at that level. Telling someone to make their design as simple as possible isn't helpful--unless the developer never even thought about simplicity, at which point it might be just enough of a nudge to prevent them from being stupid. And if it empowers a tester (who, unfortunately, are often playing the role that a nurse plays in a hospital) to point something out that they otherwise would not, then there's no doubt that a checklist is a benefit to everyone.

Posted by AdamBa at 10:02 PM | Comments (0) | TrackBack

December 07, 2007

Eric Brechner's "Hard Code" Now in Blog Form

My manager in Engineering Excellence, Eric Brechner, writes a monthly column called "Hard Code", which is now available in a book of the same name. It's an interesting glimpse inside Microsoft because it's a public collection of columns that were originally written for internal consumption. Also, Eric wrote the columns to be deliberately provocative, AND he's a funny guy and a good writer. So it's interesting to see his stuff out in public (for the book he added some explanatory text in certain cases, so if you don't know what is meant by "the SD sync window opened after the BVT pass rate for TP1 exceeded the quality gate"...well Eric's book probably won't explain THAT, but it does explain some other stuff he talks about).

When I joined EE in early 2006 I had the idea that Eric should create podcasts of his talk. This then got bogged down in some legal wrangling because podcasts, by design, are meant to go outside the corporate firewall, and there was some concern about the scandalous nature of the content. Somehow these discussions led to the idea of putting it all in a book. We still aren't doing podcasts (although there is discussion within EE of how to best use podcasts), but Eric now has a "Hard Code" blog where he has put up some of his old columns, and is now going to post his new ones. I don't always agree with what Eric writes, but if you want to see unfiltered glimpses inside Microsoft along the lines of "I still haven't recovered from the amputation of our midyear ratings, which allowed managers to send messages and employees to salvage careers after a temporary setback. They've been replaced with a time-consuming CareerCompass that contributes complexity and confusion instead of context and clarity", then surf on over and check it out.

Posted by AdamBa at 10:17 PM | Comments (2) | TrackBack