Did that change really fix the problem?

When we’re heads-down on a problem, it’s sometimes far too easy to relax the method we should follow for troubleshooting. We’re supposed to gather as much information as possible, freeze the system as much as possible, and then develop the plan for the steps to correct the problem. Then we’re supposed to make a change, test the change, and solidify the change if it corrects the error.

Most of us have learned to research what really happened, what changed, and then search the documentation, web, forums and other sources for possible fixes.

We also know that “freezing” the system in our case often means ensuring there is a full backup before we change anything. If you don’t follow this rule; don’t worry – you will. The first time you’re at fault when it all goes wrong and you don’t have a way to put it back is the time that you’ll start with this step.

It’s from here on out that the tyranny of the now sometimes gets the best of us. We may create a plan in our head, thinking “this is a simple problem” but an hour later we’re not sure what we’ve touched. Settings have been changed (and most importantly, not changed back), code has been altered, processes have been run and at some point, the problem goes away. We breathe a sigh of relief and go on about our day.

But which “fix” fixed the problem? Or which combination of them? Sure, it might not matter right now – the problem is gone – but at some point it will come back to haunt us.

So the lesson for today (and I always point these diatribes at myself as well) is that we should always follow the scientific method, no matter how “trivial” the problem: hypothesis, test, control. The “control” part is where we change the setting back from the one you changed!

Skip to main content