It's The Little Things...
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.
- 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.
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?
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.
Someone break out the bold red font. This is important. Engaging people works. Someone should tell user groups! Oh wait, someone did! ;)
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. ;)