My work is fast paced. I show up at your business with two or three days to help you improve your situation as promised. If we encounter a technical roadblock, it’s imperative for you and me to resolve it before I leave for my next assignment.
Good troubleshooting skills are vastly useful. No matter whose fault a problem is, if it’s in the way of doing what you’re paid to do, you might not be paid.
I work in the computer software industry and that is where my expertise lies. However, the principles of troubleshooting are abstract and universal.
“One bite at a time…one bite at a time”
A few times now, I’ve been asked, “How the hell do you know all this stuff?” To me, this question sounds ridiculous. Trust that I’m hating myself appropriately for using a cliché so early in this post, but I promise it will be the only one: How the hell do you eat an elephant? One bite at a time, of course.
You have probably witnessed an expert or “master” working on a problem. The master is on, and is so all the time. The master seems to know exactly how to approach every troublesome situation relating to his or her craft. The master either knows the solution to the trouble or knows where to look next to find it (which ultimately leads him to the solution or to another expert who can help). These skills, along with experience, are what separate mere competence from mastery.
Although they are likely smart people, there’s not necessarily anything intellectually spectacular about masters. Additionally, an individual that is a master on one subject is generally a novice on countless others. The point is, mastery of a skill comes from consistently exercising an efficient, honed application of logic.
When something isn’t working the way you think it should, the best way out of this situation is to break the system into manageable pieces. Don’t stare gloomily at the problem in hopes of intimidating a solution to present itself. Go to work. The process should be like a montage from a Rocky movie, except in real time and less exciting to the average onlooker.
Two immediate effects result from applying this technique:
- In breaking the system into smaller parts, your problem will take on an appearance of solve-ability rather than instill hopelessness. Keeps your moral up, in other words!
- Once you’ve identified multiple pieces of the system, you can analyze each of them in turn. Then, it’s much more likely you’ll isolate a single non-working part of the system. Fix it and you’ve succeeded.
Some people do this more quickly and mentally than others. Speed and precision come with experience. The basic procedure is always the same, though.
Dissection of the system
Step 1: Determine the requirements that yield the desired result
Every troubleshooting scenario is the same in at least two ways:
- There are one or more general requirements that must be fulfilled to yield a desired result.
- There are one or more issues that stand in the way of the requirements working to cause the desired result, instead causing an undesirable actual result.
The desired result is usually pretty easy to identify. It’s the point at which you consider the trouble to be over. You don’t have to consult with anyone else about the desired result; the fact that it’s not happening is the reason you’re troubleshooting in the first place.
The actual result is also easy to identify. It’s simply what happens instead of the desired result. Note, and this is very important, that the actual result is not the direct opposite of the desired result. It is what specifically happens instead of the desired result. It’s very important to distinguish between the two, because the latter likely contains information about the issues, where the former does not.
The general requirements may or may not be immediately obvious, depending on your experience. An internet search is a decent place to get started. Google isn’t omnipotent, however; you’ll get better results asking someone instead. Just pay attention to what that person says; you’ll need to know it again and again.
Also, if there’s a manual or documentation, familiarize yourself with it.
Dissection, Step 1, Example 1: Car
- Desired result: Your car starts when you turn the key in the ignition.
- Actual result: Your car is completely silent when you turn the key in the ignition (not “your car doesn’t start”).
- How to find general requirements? Search internet for “how does a car start” or ask anyone who’s worked on a car.
- General requirements: Spark plug generates a spark. Spark must ignite fuel in engine. Engine must compress fuel.
Dissection, Step 1, Example 2: Computer
- Desired result: Your computer connects to the World Wide Web.
- Actual result: Your computer displays an error message when you launch your web browser (not “your computer doesn’t connect to the World Wide Web”).
- How to find general requirements? Search internet for “how does a computer connect to cable internet” or call anyone who works on computers.
- General requirements: Web browser communicates with network adapter, network adapter connects to home router, home router connects to cable modem, cable modem connects to ISP.
Step 2: Find and diagnose unfulfilled requirements
At this point, you have a basic idea of what it takes to make The Thing you’re using do What You Want. If all the general requirements are met, the desired result will happen. Now you have to analyze each of the general requirements and determine which one or ones are not being met.
Depending on your level of expertise and the complexity of the system, this might be a mental exercise, a written one, or both. I like to make big headers on paper for general requirements and then scrawl detailed notes between them.
Find and diagnose, Step 2, Example 1: Car
“Okay, I’ve determined the general requirements are spark, fuel, and compression. I also found info on testing each of these requirements. Where should I begin?
Hmm, I don’t have a compression test kit, so let’s skip that requirement for now. Fuel…I filled the car with gas yesterday, so there’s fuel in the tank. Is it getting to the engine? I discovered through my research that a working fuel pump should make a whirring noise when I turn the key. But my actual result confirms there’s no noise. Maybe there’s a problem with fuel delivery. Spark…I discovered I can do a spark test quickly with only a screwdriver, so let’s try it. Yep, there’s a spark.
Spark: check. Fuel: in question. Compression: probably fine, but I’ll get my neighbor to pick up a compression test kit on the way home. Now to start investigating at the fuel pump.”
Find and diagnose, Step 2, Example 2: Computer
“Okay, I’ve determined the general requirements are connectivity between my computer, the router, the cable modem, and the ISP. Where should I begin?
I skimmed the manual for the cable modem, and it said a solid, non-blinking light means the modem is connected to the ISP. That’s the case, so I think the cable modem and ISP are okay. The router status lights are okay, and Steve’s computer is connected to the router and his internet is working fine. Therefore, I conclude the requirement not being fulfilled is connectivity between my computer and the router.
Cable modem and ISP: check. Wireless router: check. Computer’s connection to router: in question. I’ll investigate that. The actual result is the web browser is giving me an error message, so I’ll do a Google search for that message from Steve’s computer.”
You should understand from the examples why it’s important to identify the actual result correctly. It may contain key information about which requirement(s) aren’t being met.
Step 3: Repeat steps 1-2 on the unfulfilled requirements
So far, we’ve demonstrated with two examples how to identify the desired result, actual result, and general requirements of a troubleshooting scenario. We’ve also demonstrated how to isolate unfulfilled requirements that are preventing the desired result.
Notice, however, that neither of the example problems have actually been solved. So far, these are crappy examples of troubleshooting, you might think. In fact, though, these are excellent examples of how real-world troubleshooting actually works.
Troubleshooting is an iterative process. What that means is you must now apply the same steps to a different set of information drawn from the results of your last attempt.
In the example with the car, we ended being pretty confident there was a fuel pump delivery problem. Therefore, our next iteration involves determining the general requirements to yield the desired result (fuel delivery) and then finding and diagnosing any unfulfilled requirements.
In the example with the computer, we ended with confidence that the problem was with the computer itself rather than the wireless router, cable modem or ISP. Therefore, our next iteration involves determining the general requirements to properly connect the computer to the wireless router (desired result).
The number of iterations required depends on the complexity of the problem, of course. Some sources of trouble are just more elusive and rare than others. At this point, however, you should have a clear idea of how you can use the procedure above to “close in” and eliminate unfulfilled requirements and yield your desired result.
Now Go to Work
Yes, that’s all there is to it. With the information above, you are poised to learn how to fix anything.
The most valuable and rewarding thing about experience with a system is the reusability of the knowledge gained from working with that system. Reusability of knowledge is the reason you see masters working faster than others. Additionally, mastery of the principles of troubleshooting makes learning new things easier and easier. Yes, the more things you learn to do, the easier it is to learn to do additional things.
The masters are the ones who remember and connect all the conclusions they draw from careful application of the troubleshooting process.
