(Dedicated to my friend Gili, one of the few who truly understand…)
Friday morning, 6:45. I am just about to leave for my weekly cycling. I push the ‘on’ button on my computer to check e-mail. The computer starts up, but a couple of seconds later, instead of making the normal sounds of the operating system booting, it shuts down. My senses sharpen, adrenaline’s pumping. Like a wild animal sensing a threat, I enter troubleshooting mode.
Wearing my thinking cap, equipped with some experience and healthy logic, I apply rule number 1: “Perhaps the problem is not really a problem – confirm.” Naturally, I try to turn the computer on again. The same thing happens: I press the button, the computer starts running and 2-3 seconds after it shuts down.
The second rule, the “lion in the desert,” comes into play. The desert is divided into two regions, hardware and software. Although my understanding in both is minimal, I assume that the problem is not software related, as the computer is turning itself off immediately, before any software has had a chance to start up. So the lion is positioned in the hardware part of the desert (so I assume). But where, exactly?
The next rule I apply is: “seek problem in the last place that changed.” Having decided it is a hardware problem, I point at the immediate suspect: the on/off button. Recently, the button feels grimy and there’s friction when pushed.
Focused on a specific location, I apply the two following rules: “hypothesize the cause” and “propose test to confirm or refute the hypothesis.” My theory is simple: because of friction, a “regular” push is not enough, as the grime obstructs the electrical circuit. That is why after I release the button (2-3 seconds) the computer goes off. The test to verify or refute my assumption is simple: press the button and hold it in for a while so the electric circuit closes properly. Curious to see if my hypothesis is correct, I press and hold the button…The computer wakes up and 2-3 seconds later shuts down again.
Disappointed, but not desponded, I conclude the problem is elsewhere. If it is indeed in the hardware, it could be the power pack (70 NIS, not including VAT and installation). Than again, what if it is the software after all? My next rule says: “don’t give up, come up with a new hypothesis.” This rule is not very easy to apply, so instead, I use the phone.
Although it is still very early, I call my friend Gili and proudly describe the logical pathway I took: how I concluded that the problem is in the hardware; how I came up with the assumption that it is the on/off button and how I disproved it with a simple and elegant test. “And now,” I offer, “all that is left is to think of something else…”
Gili smiles modestly (well, I can’t see him, but still I can “hear” him smile) and says that my analysis is mostly right, however it is nevertheless flawed.
“The problem might very well be the on/off button, but the problem is not that it releases after several seconds. Quite the opposite, it probably stays pushed in.” Here, he goes into a detailed explanation about how the button works: It is not a regular on/off switch, but a momentary push-button. The moment it is pressed, the computer turns on, but if it is pushed for longer the computer shuts down.
I realize that since I did not know how the button works, the experiment I came up with was entirely off the marker. Gili interrupts my flow of thoughts: “I assume that because of the grime around the button, it gets stuck pushed in and after 2-3 seconds shuts the computer down. To test this, try giving it a very light push so the button doesn’t go all the way in and see what happens.” Three seconds later it was obvious that Gili was right. Halleluiah, the computer was working.
To conclude my story, allow me to offer the most important troubleshooting rule: “you need to really know and understand the system in order to solve a problem (unless you have Gili’s phone number).”
Photo Copyrights:© iStockphoto.com/evirgen
It is very useful to bring the problem’s structure to surface, otherwise we are more exposed to flawed, or even worse, wishful and magical thinking.
Mindmaps, schemas, influence diagrams, and other visual resources are great tools for this purpose.
This simple and wise story reminded me immediately of a book i stumbled upon, and then found out that it was a classic: The Design of Everyday Things, by Donald A. Norman (1988). Here is what Norman says to your point: “To understand how to use things, we need conceptual models of how they work.” He demonstrates this by an example, the thermostat. If your home air conditioner just warms the air until it reaches the temperature you set it to and then stops, then setting it to a higher temperature to make it heat the room faster is futile. But in many cars, explains Norman, the mechanism is often different - the airconditioning works by mixing hot and cold air streams. In this case, selecting a higher temperature can be a useful strategy to accelerate heating.
In short - not only for problem solving, but even for regular usage, nothing like a reasaonable conceptual model of the mechanism you are trying to manipulate (whhich is true for human relationships just as well, and goes some way towards explaining why they so often go wrong.)