Troubleshooting requires the use of reason, all problem-solving does. As reality always has the last word, make sure you’re in tune with what it’s saying. So, let’s fire up your left brain and learn about the principles of logic relevant to troubleshooting, while trying to avoid cutting ourselves with Occam’s Razor.
Induction
Induction is a type of reasoning that makes generalizations from specific facts. A classic example from the ancient philosophical texts:
- A Pontiac Trans Am is wicked cool.
- A Pontiac Trans Am is a car.
- Therefore, all cars are wicked cool.
(image: jackxface / CC BY-ND 2.0)
Okay, okay, that example was just an excuse to include a picture of a sweet ‘Merican muscle car. Also, that particular leap from specific to general is ill-conceived. Here’s the actual example from antiquity:
- Socrates is mortal.
- Plato is mortal.
- Aristotle is mortal.
- Therefore, all men are mortal.
Induction is a powerful method of organizing your discoveries about the world. Going from the specific to the general allows us to know things that would otherwise be costly to discover without this power of abstraction. The payoff comes later when you take what was learned via induction and make judgements about specific things using induction’s opposite: deduction.
Specific And General Problems
Induction’s associated pitfalls have been discussed since ancient times and could fill a library. How to proceed from a set of specifics to a generalization can be a complicated matter. This is supposed to be a slim volume of very practical knowledge, so if you’re viscerally excited by the “Problem of Induction,” you’ll have to go and study the topic on your own (preferably in a black beret and turtleneck in a coffee shop somewhere). However, I do want to acquaint you with some common induction problems that are frequently encountered by troubleshooters.
Sample size: going from specific to general based on a single example or without knowledge of the entire universe of possibilities can lead to generalizations that aren’t true. You can see the problem in the two examples above: we’ve yet to encounter a man that isn’t mortal. However, looking at one Trans Am and leaping to the conclusion that all cars are cool is easily falsifiable. Good sir or madam, have you never laid eyes on a Geo Metro?!
Induction is a chain: your conclusion is only as good as your initial premises. “Garbage in, garbage out” nicely expresses this potential problem with induction. If we had misjudged the true nature of Socrates, and he really was immortal, then our subsequent reasoning is really going to be screwed up! Put another way, if your initial specific observation isn’t right, errors will be amplified when you make a generalization based upon it.
Loose conceptual connections: the conclusion that man is mortal flows easily from man’s nature, perhaps even from the very definition of man as a rational animal whose biology as a living organism necessitates the possibility of death. In contrast, “all cars are wicked cool,” seems like a conclusion with a looser connection to the concept of a car. Cars were designed for the purpose transportation and their essential characteristics include things like doors, wheels, and engines. “Coolness” seems further afield. Of course, a generalization about all cars being cool could be true, but its disconnectedness should be a red flag for further investigation.
Deduction
Deduction reverses the direction, going from the general to the specific. Back to our friend Socrates for an example:
- All men are mortal.
- Socrates is a man.
- Therefore, Socrates is mortal.
Deduction is a very useful time-saving shortcut: if you know something is true in general, it must also be true on the smaller scale of a specific example. If “all men are mortal,” you don’t have to ask a gunshot victim if they need help. If they’re human, they are vulnerable to death, so of course they do!
Deduction is a powerful tool, but it too has its pitfalls. One problem involves improper classification: if you perceive something to be a member of a broader class when it’s really not, you will be making a big error when you apply your generalizations. For example, if you happen to be a comic book villain and you mistake Superman for a “man” (one like you and me), you may find yourself really confused when he won’t die.
Also, any errors you made during the induction phase will come back to haunt your deductions. If you made a generalization that simply wasn’t true (perhaps because you hadn’t discovered all the different possible cases) that mistake will carry through when you apply it to a specific case.
Induction And Deduction In Action While Troubleshooting
Now, let’s make the connection with troubleshooting. Understanding and applying both induction and deduction properly is important because these logical principles show up all the time when you’re on the hunt for a solution to a breakdown.
When using deduction, your prior experience with a machine will act like a generalization. “All men are mortal” is analogous to “when my car fails to start the cause is a dead battery.” However, you can probably spot the difference between philosophical truths and those encountered while troubleshooting: those turtlenecked deep thinkers sitting in coffee shops may make conclusions based on generalizations that are universally true for all time and for all cases. By contrast, the matching of symptoms with failures while troubleshooting will often be statistically true (e.g., “83% of the time, this type of problem is caused by X…”). Most systems can fail in a mind-boggling number of ways, so there’s no guarantee that the cause of a particular failure will be the same as last time, even if the symptoms are exactly the same (see “Same Symptom, Different Causes”). Your experience can be a very powerful time-saver, quickly pointing the way to a solution. However, be aware of the problem of deduction and think before applying the generalizations of your experience to all scenarios. Troubleshooting is so often about the exceptions!
Speaking of exceptions, when you find counterexamples to your troubleshooting generalizations, you need to incorporate them to make your conclusions tighter. Take a generalization, formed from your experience, like “when my car fails to start the cause is a dead battery.” One day, you will inevitably find yourself hooking up jumper cables to your car, only to have it not start! That is, the car won’t start, but something other than a dead battery will be the cause. This is exciting, because you are on the verge of discovering a new cause of your problem. Perhaps this time you discover the car is out of gas. Now, your original generalization can be narrowed to: “If the car is otherwise functional and there is gas in the tank, a dead battery will prevent it from starting.” When there’s more than a few exceptions, stating them like this can become unwieldy, so this type of information is better presented in a troubleshooting tree.
Induction will come into play during the “Cleaning Up” phase, where you try to learn from and prevent a particular breakdown from happening again. You’ll have some specific facts, the circumstances surrounding a failure, from which you will attempt to form generalizations. Those generalizations may be procedures for how to conduct future repairs (e.g., “Next time, we should attack the problem like this…”) or recommendations for routine maintenance (e.g., “We should replace this part every month…”). The challenge is making these leaps with incomplete information, keeping in mind that sometimes you may not have enough data to make a recommendation with certainty. As I’ve said before, you should always make the best guess you can with the information you do have and then correct your course as you go along by collecting and analyzing data.
Hypothesis Testing
When troubleshooting, you should look for opportunities to create testable hypotheses regarding the failure of a system. Remember the generic problem-solving formula I introduced in “One-size-doesn’t-fit-all”:
Step 1. Defining the problem
Step 2. Gathering facts
Step 3. Analyzing information
Step 4. Eliminating possibilities
Step 5. Proposing a hypothesis
Step 6. Testing the hypothesis
Step 7. Solving the problem
Troubleshooting and Maintaining Cisco IP Networks (pg. 41)
Steps 5-6 form a loop that can be iterated over and over until a solution is found. Form a hypothesis, test it and, if the problem persists, incorporate what you’ve learned into a new one. Wash, rinse, repeat.
Asserting something about the cause of the failure (and when I say “something,” I mean anything), can be a good way to start theorizing. Psychologically, I think this is because it’s often useful to have something to resist against. To facilitate the formation of hypotheses, I suggest making statements of the form: “If X is being caused by Y, then Z must be true.” Say it out loud.
Examples:
“If the car won’t start because the battery is dead, then replacing the battery will allow the car to start.”
This is a very clear hypothesis statement that includes two avenues for action: 1) testing the battery to see if it’s dead and, if so, 2) replacing it to see if the car will start.
“If the low pressure readings are being caused by a faulty pressure gauge, then replacing the gauge with one that is known to work will restore normal readings.”
Again, a good hypothesis makes the course of action to be taken obvious.
Everything Has To Fit
The goal is to find a hypothesis that integrates all of the known facts; the goal of testing the hypothesis is to expose unknown facts that you haven’t accounted for. As shown in my ode to data collection, there are an infinite number of things that can be observed and recorded for any given machine. So, you’ll never get to know everything about a particular problem. For the purposes of troubleshooting, all you really care about are the subset of the facts that are preventing the machine from working. The hypothesis testing loop above is a great way to discover these relevant items.
Keep It Simple
A bias towards simplicity should drive your evaluation of competing hypotheses. You may have heard of Occam’s Razor:
[Occam’s Razor] implies that—other things being equal—it is rational to prefer theories which commit us to smaller ontologies.
The Stanford Encyclopedia of Philosophy
“Smaller ontologies” means theories with fewer entities, a parsimony of thought. Occam’s Razor is sometimes misunderstood to mean that you should always favor simpler explanations over more complicated ones. Simple or complex, the hypothesis must always fit the data. If you’re trading simplicity for an equal amount of explanatory power, Occam’s Razor doesn’t say that one hypothesis is necessarily better than the other.
While troubleshooting, it’s easy to get carried away with complicated explanations for a failure. Are you beginning to entertain theories involving Leprechauns and Unicorns, prancing around on epicycles? That’s your wake up call that you might be on the wrong track. Most likely, you’ve subconsciously blocked off an entire realm of possibilities or haven’t followed the evidence to its logical conclusion.
References:
- Header image: Fleur, photographer. Retrieved from Unsplash, https://unsplash.com/photos/QreQvdSr-Wc.
- Ben Bayer. Introductory Practical Logic.
- Amir Ranjbar, Troubleshooting and Maintaining Cisco IP Networks (Indianapolis: Cisco Press, 2010), pg. 41.
- Simplicity, The Stanford Encyclopedia of Philosophy.
THE ART OF TROUBLESHOOTING 