Unless you are extremely lucky, you have spent time “wandering up the garden path” when it comes to troubleshooting a technical problem. In some cases, one can spend hours, even days, pursuing an avenue that proves to be fruitless.
Psychological research has found that people often jump to conclusions rather than arriving at them deductively. When asked to explain why they came to the conclusion they did, they have difficulty explaining in detail how they reached their initial conclusion.
What does this have to do with technical support troubleshooting?
When troubleshooting a technical problem many of us “race ahead” and use our intuition to reach a hypothesis as to a possible cause before we’ve had time to assess the available body of evidence. We tend to jump to a conclusion based on one or two facts. When we use our intuition to solve a problem, we look for things that confirm the conclusion. If we find something that confirms that conclusion, we become even more certain of that conclusion. Most people also unconsciously ignore obvious data that would disprove their incorrect hypothesis because the first reaction to a conclusion reached at through intuition is to try and confirm it rather than refute it.
IT Pros often have to jump to conclusions because we often operate from incomplete data. Sometimes this is because we are rushed. Sometimes it is because we are smart a4$3$ who are a bit enamored with how clever we are ;-), cleverer than ordinary people, who are only clever about ordinary things.
Back in the 1930’s a philosopher named Karl Popper came up with the idea that scientists should attempt to falsify their hypotheses rather than to verify them. The basic reasoning is that while you cannot prove a hypothesis to be true by finding a number of different confirming instances (though confirming instances do make you more confident in the truth), you can prove a hypothesis to be false by finding one valid counter-example.
Which brings us back to troubleshooting methodology. You’ve probably diagnosed hundreds, if not thousands, of technical problems in your career as an IT professional. Out of all of those times, how many times has your first idea about what caused the technical problem actually been correct? How many times have you spent hours chasing “wild geese”? Chances are you’ve spent a not insignificant amount of time barking up the wrong tree because you’ve overlooked a critical bit of evidence that would have had you immediately discount the conclusion if you’d seen it earlier.
The idea behind using a falsificationist method is to treat your initial conclusions about a complex troubleshooting problem as untrustworthy. Rather than look for something to confirm what you think might have happened, try to figure out what evidence would disprove that conclusion. You’d be surprised how obvious evidence you unconsciously ignored becomes unmistakably obvious when you are looking for a refutation. If you disprove your initial conclusion, you’ve just saved yourself a lot of time in chasing a wild goose. You can discard it, moving on to another theory. If you can’t find any evidence that your conclusion is wrong, you can have a bit more confidence that you may be on the right track. The difference between this and the way that most people approach problem solving is that a falsificationist methodology allows you to quickly discard time wasting avenues. Because people try to confirm their conclusions, they often find things that reinforce their bias about what has happened. The more reinforcement they give themselves, the longer they will persist on that path. By looking for evidence that confirms what we’ve already decided, we become more set in our opinion that what we’ve decided is what actually happened.
Trying to disprove your conclusions may not give you the correct answer right away, but at least you won’t spend a couple of hours chasing what turns out to be an incorrect answer.
To learn more about Falsifiability, consult the following article on Wikipedia:
