Change Just One Thing

Most troubleshooting exercises will be a narrowing to a single failed component (and hopefully, it’s just one broken part!). Paring down a list of possibilities leads to isolation, which in the context of troubleshooting means that you can confidently point to a particular part of a system and say, “The problem is somewhere in here.” After you’ve made your best guess as to the cause and you’re ready to test a particular fix, only change one variable at a time. Most importantly, you should re-test for the failed condition after each change. If you don’t, you may solve the problem, but you won’t know what you did to solve it.

You should view each troubleshooting session as an opportunity to learn; changing multiple things simultaneously will destroy the knowledge that could be gained from a failure. If you’re the kind of person that likes to continually improve the world around you (or, close enough, you’re responsible for making a system work), you should crave getting to the root of a problem. Since if often takes multiple failures to have that “Aha!” moment of realization, treat every breakdown as a precious lucky break to start this learning process.

Economy Of Action

I’ll often be talking with someone who got something professionally repaired and they’ll relate to me how pleased they are:

Me: “What did they end up doing to your car?”
He Who Just Paid A Large Repair Bill: “Let’s see, they replaced the fuel pump, battery, hoses, fan belts, and adjusted the valves.”
Me:“Wow, but…which of those repairs fixed the problem?”
He Who Just Paid A Large Repair Bill: “I don’t know, but it’s definitely gone now!”

The problem better be solved, because every component even remotely related to it was replaced! The economics of troubleshooting often favors swapping over repair, especially if the cost of parts is low and the price of labor is high. But, keep in mind the counterbalancing “cost” of shotgun-style repairs: they do little to advance your knowledge of what went wrong.

Of course, I’m not the first person to note the necessity of only changing one thing at a time when determining cause and effect. This is a bedrock principle of the scientific method, which involves modifying a single “independent variable” and observing the results. The people in white coats do this to ensure that they are conducting a “fair test” and that their results will be repeatable for other scientists. A good experiment has static conditions for every round of data collection, save for that lone variable being adjusted, to ensure that any changes stem from it alone.

The scientific method has much to teach the troubleshooter: think of the broken system’s output as the dependent variable in your fix-it experiment. You form your hypothesis for the cause of the failure, and your proposed fix is the independent variable that will be changed. If you find that your hypothesis was wrong (and therefore you’d like to test another theory that involves a different fix), be sure to put the previous independent variable you changed back to its original condition. This means putting the system back exactly like you found it: settings, parts you may have taken out, etc.

Before I knew better, there were so many times where I would attempt a different fix, but not put a machine back to the way it was before trying the previous one. Not only does this scenario violate the “change just one thing” principle, but the change you’ve failed to revert may now be a new, additional cause of non-operation. Prepare for frustration as now you’re troubleshooting two problems instead of one!

References:

• Header image: Agrl. Dept., Biological Survey laboratory. ca. 1920. [Photograph] Retrieved from the Library of Congress, https://www.loc.gov/item/2016852276/.