When troubleshooting problems, we often find ourselves mired in a sea of options.  Google searches, technical documentation, tricks from our magical networking bag, and so on.  And more often that not, it takes more than one solution to actually fix a problem.  Magic bullets are very hard to come by in Information Technology.  So, when Google search option #1 fails, it’s time to move down the list to option #2…

WAIT! STOP RIGHT THERE!!!

Yes, you heard me.  Before you move on to option #2, you’ve got something to do first.  Before you get that big head of steam built up troubleshooting, you’ve got to clean up after yourself.  Yes, it’s time to undo option #1.  Now, I know what you might be asking yourself right now: “Huh?  What?  Undo something?” That’s absolutely correct.  If you try something that doesn’t work, you need to back out that change before you move on.  Why???

1.  If you end up trying 15 things to fix this particular issue, and one of them finally works, which one actually fixed the issue? Your first reaction is to say “Well, duh.  The last thing I did is what fixed it.” Usually that’s a good answer.  Unless Thing #9 needed 5 minutes to fix the problem in the background while you tried #10-#15.  Or, worse, #9 did something that allowed #13 to fix the issue.  The idea is that by backing out the changes if they don’t work, you can pinpoint what works more quickly.  Or, in some cases, narrow down a list of things that need to be done in concert to resolve the issue.  More than once I’ve asked someone how they fixed a problem only to be met with a shrug of the shoulders.  As a consultant or a technical resource for your company it’s vital to remember that if you can’t explain to a customer or your boss what you did to fix the problem, you didn’t actually fix anything.

2.  You don’t want to introduce any extra issues into the mix. If you don’t back out your changes before trying something new, there’s a very good chance that you’ll introduce an unexpected variable into the situation that could make your life miserable later on.  Or, in a worse case scenario, one of your previous ‘fixes’ causes a totally different issue after you’ve finished troubleshooting the original problem.  If you always take the time to back out irrelevant changes as you eliminate them as solutions, you don’t have to worry about them causing unforeseen interactions with your ultimate solution.  You don’t want to end up not being able to fix a routing issue because the routers won’t form neighbor relationships because you configured an access list that drops all multicast packets in a previous attempt.

As long as you remember to clean up as you go and back out any non-useful or non-functional changes, your troubleshooting life will be much easier.  You’ll find that you can more confidently explain solutions to customers and coworkers, as well as not introducing unforeseen consequences into your efforts.  You’ll look like a hero, money will fall from the skies, and the meek will worship the ground that your superior troubleshooting skill occupies.  At least, I think that is what’s supposed to happen if I just change this one other setting…