The frantic pounding on your door jolts you awake, and noticing that it is three in the morning doesn't calm your nerves. You peek out the window, not really knowing what to expect, but any speculation is immediately cut off by the fire you see climbing up the side of your house. Before you can react, a man appears (the one who was pounding on the door, you guess: funny how the mind can still reason so quickly under such stress), takes your garden hose and begins to spray water onto the fire. By the time you stumble out the front door, the fire is almost out. Panting, you stumble up to him and stare at the scorched wall. “I was on my way home from work,” he says, “and I saw the fire. Lucky I put it out before it spread.” You thank him for helping, and offer a reward. He turns down the offer, saying he was just glad to help.
Of course you would be grateful to someone who saved your home from a fire. But how would you feel if you later learned that he had also set the fire? What kind of lunatic would do that? Certainly you would not feel like offering a reward under those circumstances.
Yet we routinely praise and reward people who do the same type of thing in software business. A sales person runs into trouble with a customer, waits until the customer is really upset (due to inaction), and then “helps” to solve the problem by short-circuiting company procedures to “do the right thing for the customer.” A software team waits until late in the project to announce that certain serious problems – which they had known about for a long while – are going to cause a schedule slip. The team then makes a heroic effort to finish, and is thanked afterward for “getting it done.” We are happy when a vendor fixes a problem in their software, after much complaining and arguing from our side, even though all the vendor did was fix a problem it created. Whether through ignorance, incompetence, lack of planning or gamesmanship (it is easier to force an issue with a preferred solution if time to consider the problem is artificially cut), we are are grateful that the problem was solved and that the team “pulled together” at the crucial point. We breath a sigh of relief and move on, waiting for the next fire.
But we fail badly each and every time we move on with first looking back. We fail to ask the key question: How did the emergency arise in the first place? In the heat of the emergency, such questions are usually cut off with well-intentioned statements like “this is not the time to point fingers” (many times by those who created the emergency, for obvious reasons). Although that is probably right (during the emergency you need to react to address the challenge), it does not mean that you shouldn't ask in retrospect. You have lost a chance to learn and avoid future emergencies for the same reasons, and you have set the stage to reinforce the bad behavior that relies on such emergencies to get things done.
