â€œWhat do I always say? Anyone can cook.â€
I am often reminded of this quote from Disney Pixarâ€™s Ratatouille when I think about troubleshooting. But is it true that anyone can troubleshoot computer problems or debug code?
The Troubleshooting Process
Much like cooking, troubleshooting follows a simple recipe that anyone can follow. Troubleshooting can be broken down into 4 steps:
- What are the symptoms?
- Can the problem be reproduced?
- What changed since the last time the system worked?
- Find a solution to the problem.
1. What are the symptoms?
This step will usually be completed by the end users of your application – their complaint will be the catalyst in starting the troubleshooting process. You want to identify any symptoms that are occurring, to help narrow down the problem:
- Is the application crashing?
- Are you receiving an error message?
- Are you getting unexpected results?
2. Can the problem be reproduced?
Sometimes an error can be a one-time occurrence (these can be a little bit more difficult to troubleshoot) – such as a connection to an external database is not available temporarily, but after waiting an unspecified amount of time the system works correctly.Â Sporadic errors are more difficult to troubleshoot as there might be several things wrong (at the same time) and may require a problem process of elimination.
For other issues, you want to identify a predictable pattern to the error occurring. For example, if I enter a zero into this field and press calculate, I receive a divide by zero error message.
3. What changed since the last time the system worked?
A program should never change its behavior on its own (unless you are programming A.I.). Something must have changed somewhere in the system, it could be code related, hardware related, operating system related, etc. The change may resulted from something that was done unintentionally, such as Windows installing automatic updates or malicious code.
Many applications and operating systems will have logs that will identify any that may have happened, these will be your primary source for determining changes.
4. Find a solution to the problem.
This is the step where troubleshooting becomes more of an art.
Steps 1 – 3 are really a discovery process – the answers can usually be obtained by asking end users some basic questions.
Occasionally, the solution to a problem is a relatively simple fix and the troubleshooting process ends here. If the solution is not inherent after the discovery process, research needs to occur.
The difficulty lies in knowing where to look. This, unfortunately, is something that will only come with experience. One of the first things that new programmers confront is, â€œhow do I know what data types are available or which one to use?â€ If you look at it, different variations of this question can be used no matter what profession you have:
Chef: â€œHow do I know what ingredient to use?â€
Doctor: â€œHow do I know what to prescribe for those symptoms?â€
Baseball Player: â€œHow do I know how to swing the bat for the most impact?â€
After you’ve tried a solution, did you fix the problem? Troubleshooting may become a recursive process â€“ because you may inadvertently introduce new errors and will need start the troubleshooting process again finding a solution to the new problem.
The good news is there are plenty of resources (see 17 Websites for Sharing Programming Knowledge) where we can seek out expert advice and find answers to our questions.
Experience is what sets apart the beginners and the masters.
Whether itâ€™s cooking or troubleshooting, anyone can do it – However, each person will have varying degrees of success depending on the experience level.