Solved

General techniques:  Problem solving and troubleshooting

Posted on 2004-08-06
1
269 Views
Last Modified: 2010-05-18
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
0
Comment
Question by:knowlton
1 Comment
 
LVL 37

Accepted Solution

by:
gregoryyoung earned 500 total points
ID: 11740736
An example I always give is to make people give specific directions on how they get to work in the morning ... then they begin to realize the types of rules that are required in code (which is very important). I then in their process of telling me start asking questions of "What if the street is closed ?"

I tend to ALWAYS put in logging that is optional ... not necesarily a bad technique for "     -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)
"

Another thing I tend to hit on is isolation and reproduction in a controlled environment because they are the most important parts of debugging an issue.
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

Introduction                                                 Was the var keyword really only brought out to shorten your syntax? Or have the VB language guys got their way in C#? What type of variable is it? All will be revealed.   Also called…
Introduction Although it is an old technology, serial ports are still being used by many hardware manufacturers. If you develop applications in C#, Microsoft .NET framework has SerialPort class to communicate with the serial ports.  I needed to…
This tutorial demonstrates a quick way of adding group price to multiple Magento products.
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now