We have all experienced that magical moment. After countless frustrating experiments and racking our brains, the objects we focused on began to work. The 3D printer finally produced good output. The hacked laptop finally started. The car engine finally grunted. The question is, do we know why it started working?
This is more important than you think. Knowing the answer allows you to confirm that the core problem has been solved, otherwise you may just have solved one symptom. Lack of understanding means that solving one problem may lead to another.
The solution is to use an orderly troubleshooting method. We are talking about a structured problem-solving technology, if used properly, it can help us solve the core of the problem without leaving any loose endings. Such an approach will also let you know why any solution is ultimately effective or ineffective, and provide you with repeatable results.
It is unreasonable to expect us to be able to effectively repair anything we don’t understand. For example, if the car is not functioning properly, if you don’t understand the basics of ignition timing, fuel delivery, and how the engine is at least at a basic level, then trying to fix it will be meaningless.
If you are trying to build something from scratch or make major changes to an existing product, you need to have an in-depth understanding of what the final product should look like. If you have not kept up with these things, then it may be time to delve deeper, as they say, to delve into the subject at hand.
Wikipedia, technical articles, forums, social media communities (groups.io, facebook groups, reddit, etc.), and of course Hackaday are all possible resources for learning. Once you understand how any system should work, you can begin the next step of troubleshooting: the troubleshooting process.
Now that you have become an expert on the subject of your choice, it’s time to learn more about the problem. With our clear vision of the successful process and the elimination process, we will conduct an investigation. Yes, we want the complete Sherlock Holmes! If you grew up playing some kind of trademarked and copyrighted board game, then you know how it works.
The goal is simple: identify all the steps that make up a successful process, and then check them one by one from the first step-even if (especially if!) you think you already know where the problem is. step by step. Not multiples, definitely not all. There is no skip. only one. Then, after you check only one item at a time, you will write down: Did it solve the problem? Yes? Do not? not sure? It’s ok.
At each stage, record your results and then move on to the next item in the list. Recording the results is critical to the process. Sometimes we do not have all the facts until the latter part of the investigation. Therefore, being able to view notes will help us discover trends that we have never noticed.
Even if you think you have solved the problem, continue to browse your list. Check the entire system to ensure that the entire system is working as it should. If you only view part of the process, troubleshooting is incomplete.
In more complex systems, the layered approach will be very useful. Start with a high-level overview of the system at hand. Perform the process step by step until you find something damaged. After isolating the problem area, restart the troubleshooting process in the problem area and take notes at any time. If you do solve the problem, return to the first level of troubleshooting and continue until the process is complete. This will help you answer the next question.
If you have identified and resolved the core problem you believe to be, then it is time to verify that the fix is effective. The best way to do this is to test your project or process in the way it will be used. Sometimes it’s simple: something works and it’s fixed; there is almost nothing to do between the two. Other times, more extensive testing is required. Imagine repairing a car that cannot be started, handing over the keys to the owner, and then finding it hard to find that it has no brakes!
So, so to speak, you may need to take a “test drive”. The goal should be to verify that instead of solving one problem, you created two other problems and whether the entire system is working as designed.
Like any method or process, when we are not doing it right, it is very likely that we are doing it right. Troubleshooting is no exception. If we skip or don’t take notes altogether throughout the process, it is easy to miss the question. Likewise, if we don’t fully understand the subject, we may not be able to recognize when it doesn’t look right.
When I was young, I heard the sadness of the backyard mechanics that they replaced parts worth hundreds of dollars, but the problems they encountered were not resolved. I clearly remember that they blamed their problems on the novel “electronics” (fuel injection). The reality is that they don’t understand the system they are using, so they can’t troubleshoot it effectively, so they stop analyzing the problem and just react to it by throwing parts at it until it has hope to work. This is another way to fail during troubleshooting.
In some cases, the exact troubleshooting process may be overkill. Relying on the car analogy again, imagine that you have an old fuel-injected car that is not functioning properly. It may be due to the age of the entire system, no one thing can really solve the problem. Years of wear, poor connections, and worn parts can all lead to fuzzy problems that are difficult to reproduce. In addition, we don’t know when the system was last repaired. In this case, a shotgun approach may be needed. No, I didn’t mean to take it out and shoot!
The above troubleshooting method can be described as a high-precision rifle: we carefully aim and apply repairs. The shotgun method is just the opposite: we aim at the general direction of the problem and fire multiple projectiles, hoping that one of them will hit the target and solve the problem.
In our bad EFI example, it may not be unreasonable to replace all sensors and any damaged connectors. The mechanical parts, such as the throttle body, will be rebuilt later. Even replacing the fuel pump, filter and cleaning the fuel delivery system with fuel additives can help. Then, once the system is restored to a known state, it can be tested and appropriate troubleshooting techniques can be used to double-check for any remaining failures.
Another use case of the shotgun approach is when we have a time-sensitive issue that needs to be fixed. The underlying problem may have only a few known causes, so in some cases, it may be faster to apply all the fixes at once. For example, we may not have time to properly troubleshoot mission-critical servers with unknown hardware issues. Replace the storage system on a new computer, it will soon be back online, and then the previous hardware can be tested without time limit.
In any case, having a thorough understanding of the system you are dealing with will help you take the right approach to solve the problem.
You may have noticed that the troubleshooting methods discussed are very similar to the scientific methods that at least most of us learned in school. This is why taking notes is so important.
Adam Savage has a famous saying: “Remember children, the only difference between screwing and science is to write it down!” (This is Later attributed to Alex Jason.) And this is the point here: writing things down and writing down whether they are effective is a vital part of the whole process. Otherwise, we just pierced into the darkness blindly.
I hope this attempt to fix tedious things is useful to you. Do you have your own troubleshooting stories, methods, or “aha!” moments to share? Be sure to let us know in the comments below!