asked on
General techniques: Problem solving and troubleshooting
I have been asked to give a 30 minute presentation on problem solving and troubleshooting for an upcoming IT Staff meeting.
The Experts in this TA are skilled in analysis. I am counting on you to review my presentation so far and give constructive criticism and new ideas. Even though my audience will be technically savvy...the problem-solving ideas do not have to be IT-centric at all.
==========================
Here is what I have so far:
MENTAL PREPARATION:
There is some mental preparation before tackling any problem.
-Mindset is important. Look at problems as intellectual puzzles to be solved. Avoid internalizing the problem or seeing the problem as a problem with YOU, especially if you've made a significant contribution to the project along the way. As Spock would say, avoid letting emotion cloud your judgement. Nobody thinks well when they are upset.
GUIDELINES:
-A lot of important information can be gathered when you are FIRST told about a problem. Capitalize on gathering this information as close to the problem event as possible. The more time that passes, the more difficult it may become to find out how the problem happened, when it happened, and how to reproduce the problem.
-Try to define steps that can be followed to reproduce the problem.
JOKE:
There are four engineers travelling in a car; a mechanical engineer, a chemical engineer, an electrical engineer and a Microsoft Windows computer engineer. The car breaks down.
"Sounds to me as if the pistons have seized. have to strip down the engine before we can get the car working again", says the mechanical engineer.
"Well", says the chemical engineer, "it sounded to me as if the fuel might be contaminated. I think we should clear out the fuel system."
"I thought it might be a grounding problem", says the electrical engineer, "or maybe a faulty plug lead."
They all turn to the Computer Engineer who has said nothing and say, "Well, what do you think?"
"Let's close all the windows, get out of the car and then get back in again?" says the computer engineer.
-Pay attention to intuition. The first guess is often the correct one.
-Document your findings as you go to keep from re-visiting the same places unnecessarily.
-Ask for help in areas where you have less expertise.
-Refer to your findings when you do this, so interested parties have the info they need to help you or offer more insights.
Steps While Troubleshooting:
1) Scan - done very quickly (5 minutes for this activity). Catches 80% of the bugs
-Purpose is to eliminate easy to fix human errors
-Syntax
-Misspellings
-Simple logic errors
STEP 1 is “Done” when you start to get stuck or the problem is not immediately recognizable.
2) Perform “Deep Search” / Extended Troubleshooting
-Purpose is to find the logic errors that are not recognizable during a quick scan of the code. Consider that “bad” design may be the problem.
-Force yourself to SLOW DOWN. If someone is available to help you, try explaining the problem step-by-step. Sometimes the act of forcing yourself to explain the problem will yield the answer. For some people, having a self-dialog as you go can accomplish the same thing...and sometimes an interactive approach is more useful.
-Avoid “glossing over” areas that you think are working. The temptation to gloss over an area should raise a flag (do you really understand what is happening in a particular function or subroutine?)
-Establish internal dialog with yourself….explain why each line of code exists, and why it is necessary. Doing this is the reason most bugs are found when someone else is sitting next to you and asking you to explain what is happening in the code. The process of explaining the bug to someone else forces you to explain areas of the code you have been glossing over when no one is around requiring you explain it.
-Set breakpoint and go through code line-by-line, looking for an explanation as to why the problem is occurring.
-Create “output” messages to show values, etc. Some available tools are:
-MsgBox
-Immediate Window
-Logs (temp table or a physical file)
-Watches (variable values while stepping through code)
Questions to Ask Yourself While Troubleshooting:
1) What is the Input (list each value coming into the system)
2) What is the expected Output? Did it happen? Why not?
3) Hard to solve bugs are where you get a different output than the input should have given you.
Input
Transformation Process (Validation, or some function or subroutine)
Output
4) Divide and Conquer. Break into smaller pieces. Create a small application that does ONLY the one thing you are having trouble with.
5) With SQL Statements: Remove WHERE condition and see if you still get errors.
6) Reduce complexity where possible.
7) Pay attention to RECENT changes to that portion of the code or related code that may have broken the system.
Other Notes:
Distinguish between solving symptoms and the root problem. Fixing the symptoms does not mean fixing the problem that causes it.
EXAMPLE OF HELP DESK TROUBLESHOOTING METHODOLOGY:
http://www.inetdaemon.com/tutorials/troubleshooting/general.html
RESOURCES:
User Manual. RTFM.
Google
Dedicated Newsgroups
Co-workers
Brainstorming
The Experts in this TA are skilled in analysis. I am counting on you to review my presentation so far and give constructive criticism and new ideas. Even though my audience will be technically savvy...the problem-solving ideas do not have to be IT-centric at all.
==========================
Here is what I have so far:
MENTAL PREPARATION:
There is some mental preparation before tackling any problem.
-Mindset is important. Look at problems as intellectual puzzles to be solved. Avoid internalizing the problem or seeing the problem as a problem with YOU, especially if you've made a significant contribution to the project along the way. As Spock would say, avoid letting emotion cloud your judgement. Nobody thinks well when they are upset.
GUIDELINES:
-A lot of important information can be gathered when you are FIRST told about a problem. Capitalize on gathering this information as close to the problem event as possible. The more time that passes, the more difficult it may become to find out how the problem happened, when it happened, and how to reproduce the problem.
-Try to define steps that can be followed to reproduce the problem.
JOKE:
There are four engineers travelling in a car; a mechanical engineer, a chemical engineer, an electrical engineer and a Microsoft Windows computer engineer. The car breaks down.
"Sounds to me as if the pistons have seized. have to strip down the engine before we can get the car working again", says the mechanical engineer.
"Well", says the chemical engineer, "it sounded to me as if the fuel might be contaminated. I think we should clear out the fuel system."
"I thought it might be a grounding problem", says the electrical engineer, "or maybe a faulty plug lead."
They all turn to the Computer Engineer who has said nothing and say, "Well, what do you think?"
"Let's close all the windows, get out of the car and then get back in again?" says the computer engineer.
-Pay attention to intuition. The first guess is often the correct one.
-Document your findings as you go to keep from re-visiting the same places unnecessarily.
-Ask for help in areas where you have less expertise.
-Refer to your findings when you do this, so interested parties have the info they need to help you or offer more insights.
Steps While Troubleshooting:
1) Scan - done very quickly (5 minutes for this activity). Catches 80% of the bugs
-Purpose is to eliminate easy to fix human errors
-Syntax
-Misspellings
-Simple logic errors
STEP 1 is “Done” when you start to get stuck or the problem is not immediately recognizable.
2) Perform “Deep Search” / Extended Troubleshooting
-Purpose is to find the logic errors that are not recognizable during a quick scan of the code. Consider that “bad” design may be the problem.
-Force yourself to SLOW DOWN. If someone is available to help you, try explaining the problem step-by-step. Sometimes the act of forcing yourself to explain the problem will yield the answer. For some people, having a self-dialog as you go can accomplish the same thing...and sometimes an interactive approach is more useful.
-Avoid “glossing over” areas that you think are working. The temptation to gloss over an area should raise a flag (do you really understand what is happening in a particular function or subroutine?)
-Establish internal dialog with yourself….explain why each line of code exists, and why it is necessary. Doing this is the reason most bugs are found when someone else is sitting next to you and asking you to explain what is happening in the code. The process of explaining the bug to someone else forces you to explain areas of the code you have been glossing over when no one is around requiring you explain it.
-Set breakpoint and go through code line-by-line, looking for an explanation as to why the problem is occurring.
-Create “output” messages to show values, etc. Some available tools are:
-MsgBox
-Immediate Window
-Logs (temp table or a physical file)
-Watches (variable values while stepping through code)
Questions to Ask Yourself While Troubleshooting:
1) What is the Input (list each value coming into the system)
2) What is the expected Output? Did it happen? Why not?
3) Hard to solve bugs are where you get a different output than the input should have given you.
Input
Transformation Process (Validation, or some function or subroutine)
Output
4) Divide and Conquer. Break into smaller pieces. Create a small application that does ONLY the one thing you are having trouble with.
5) With SQL Statements: Remove WHERE condition and see if you still get errors.
6) Reduce complexity where possible.
7) Pay attention to RECENT changes to that portion of the code or related code that may have broken the system.
Other Notes:
Distinguish between solving symptoms and the root problem. Fixing the symptoms does not mean fixing the problem that causes it.
EXAMPLE OF HELP DESK TROUBLESHOOTING METHODOLOGY:
http://www.inetdaemon.com/tutorials/troubleshooting/general.html
RESOURCES:
User Manual. RTFM.
Dedicated Newsgroups
Co-workers
Brainstorming
C#
Last Comment
gregoryyoung