Better

In Better, Dr. Atul Gawande mentions several basic things medical professionals can do to drastically impact the rate of hospital-passed infection. His first point is: Wash your hands.

This seems simple on the surface, but the time requirements for properly washing one's hands using traditional soaps is noteworthy: Once specified and quantified, this becomes a time-consuming exercise.

The procedure: - Remove watches and jewelry - Wet your hands with warm water - Dispense soap and lather everything from 1/3 of the forearm down for 15 - 30 seconds - Rinse for 30 seconds - Dry completely, then use the towel to turn off water. - Repeat after any new contact with a patient.

Let's try to be realistic and say we can remove our watch and jewelry in 6 - 10 seconds. We can turn on the water and wet our hands in 5 seconds. We have 45 - 60 seconds lathering and rinsing. Then 15 seconds drying and finishing up. That's 1:11 - 1:30 each time a medical professional touches a patient. Add to the mix: some medical professionals are expected to interact with 20 patients per hour. That's 3 minutes per patient - and nearly half of that time is to be taken doing "unproductive" work - washing one's hands. Why do they do it? People die if they don't. The statistics are sobering: 2 million people annually catch a bug in the hospital in the US alone. 90,000 of them die.

Of Hand-Washing And Software...

Andy, what does any of this have to do with software?

I'm glad you asked. Like Dr. Gawande and lots of you, I believe we can also do Better. What's the equivalent of "washing our hands" in software development? My friend Harper Trow says "if you mean the most basic practice - the most common sense, I would say use source control". Harper also points out source control is Item #1 on Joel Spolky's Joel Test post.

Now you don't need to use source control. And you don't need health insurance. These are equivalent statements, unless you are (and will remain) in perfect health or are (and will remain) a flawless coder. Source control is not suspenders-and-a-belt - it's a belt and you have no suspenders. You need it or you're in danger of showing something you (or we) may not wish to see. It's as optional to the software development process as security to the information technology enterprise.

Source control can be setup and configured in a day, learned on Day 2, and mastered in a week. You don't have to start with a full-blown Application Lifecycle Management (ALM) Suite, you can grab an open-source project or trial edition and install it on your Dev server. Most products integrate into Visual Studio and many into SSMS. It's not hard, it just requires a bit of discipline and the desire to do better.

Changing

Dr. Gawande cites several attempts, some successful and some not, to implement change in the personal habits of people - change which is literally a matter of life and death.

The failures of these attempts are staggering.

The implication for us is this: If humans are incapable of change when life itself is on the line, how much less capable are we when it's "just software?" This is my theme and central question.

What makes developers change habits? What causes DBAs to do things differently? What drives us? motivates us? changes us? makes us better? Is it even possible?

What Worked?

At the veterans hospital in Pittsburgh, Jon Lloyd attempted a strategy based on Positive Deviance. (Positive Deviance is exemplified in Good To Great - an awesome book on patterns of business success.) It worked like this: They held short meetings with everyone in the hospitals. Everyone. Doctors, nurses, janitors, food service workers, even patients. They made one statement: We're here because of the hospital infection problem and want to know what you know about how to solve it.

Holy smokes. Asking the people that do the work - that's crazy talk!

It worked, but not for the reasons you may think. It worked because it engaged the population. When anyone actually acted on the ideas presented - which by and large were repeated in every 30-minute meeting - the people in attendance felt someone was listening to them and responded by helping implement their own ideas.

Listening, then acting upon what's said, prompts participation like nothing else. There is no substitute. How's a leader to get started?

Here's How To Start

Invite the team to lunch and pop the question. No, not that question. This one: "What do you know about doing our job better?" Let the ideas flow - don't respond and for goodness' sake do not defend anything. Listen. Then listen some more. And then - you got it - listen yet more. Make notes. Nod. Engage.

And then implement some of the suggestions.

How hard is this? Everyone likes to be appreciated and almost everyone wants to do a good job. Lead them. By example. You want them to do a good job? You do a good job leading first. You be Better first. Unless, of course, you want them leading. ;)

Comment Notification

Comments

Great post, and I can certainly relate to the idea of "Hand Washing" in software. It seems that there are quite a few things such as design, testing, etc... that seem to get left off the list because it costs too much time up front. But in the end, the payoff is usually huge.

But source control? Are there really that many shops out there who don't use source control? As a professional developer, I just can't wrap my mind around that. But then again, I have been using source control for pretty much as long as I have been writing software. When I'm not using it I feel dirty, even on personal projects. :-)

Harper shared other tidbits that did not make the post. One was this: The last number he saw about developers that do not use source control was around 40%. That's a shocking number to me - and likely to you as well.

40%? Seriously? You couldn't make me work for someone with no source control for anything. If they don't even use source control then I can't fathom how the rest of their development goes. :-) Now that is what you call "programming by coincidence".