“It was working yesterday. What changed?”
We’ve all said it. It’s said in moment of desperation when trying to figure out why something is not working.
While this technique may have its place, a closer examination shows it to be an inefficient way to troubleshoot an issue.
Let’s look at some example problems. You walk outside in the morning to go to work, and your car doesn’t start. Uh oh. You’re gonna be late. Do you ask yourself “What’s changed?” Of course you don’t. It doesn’t provide any useful information about locating the source of the issue. Pretty much everything has changed. The weather is different; maybe it’s colder and the starter doesn’t have the juice to turn the engine. Maybe the battery is now discharged because you left the dome light on. Every component in the car is one day older than it was yesterday and maybe one of them is dead. Likely you’ll check a couple obvious issues, like the battery and fuel level, and if that isn’t it, you’ll likely call for help.
Let’s look at another example. You walk into a room and flip the light switch and the light doesn’t come on. Do you ask yourself “What’s changed?” I highly doubt it. Again, it doesn’t provide any useful information because the number of variables is huge. You’ll probably try another switch. You may try another light bulb, or check that other things on that power circuit are getting power. If those don’t work you’ll probably call someone to help.
Now let’s look at an example in the virtual world. You sit down at your desk in the morning, launch your favorite email client, and discover that it just throws an obscure error and refuses to start. Do you ask yourself “What’s changed?” Most people do!
My theory is that people view software an an enclosed system with no external inputs. As such, people expect it to work forever unless something changes. Unfortunately, this is far from the truth. Firstly, software runs on hardware which is a hidden input/variable into any software system. Your hardware is one day older than it was yesterday. Secondly, most modern applications use the Internet is some fashion; certainly, your email client does. What’s changed on the Internet since yesterday? Pretty much everything. Maybe your router got a new address via DHCP. Maybe your clock is unsynced. Maybe your ISP changed its routes. Maybe your service provider moved the email server. Maybe DNS is resolving differently. Maybe the email server is down or busy.
If you ask yourself “What’s changed?”, then just like our examples in the physical world, the answer set is usually so large that it doesn’t help you isolate any possible causes. If you really think there is only thing that changed, it is likely you are ignoring many inputs/changes because you don’t see any way they changed, or you don’t see how they could relate to your issue.
So how do you go about properly troubleshooting the issue? The first step is to admit that if you find yourself asking, “What’s changed?”, that it is likely because you have no idea where the problem lies and no idea how to go about finding it. The second step is to devise a scientific method to troubleshoot different aspects of the system to isolate and locate the issue. If the second step fails, the third step is to call someone who can help.
“What’s changed?” does have its uses. It is a hack/shortcut that can often lead to a quick answer without having to troubleshoot the issue from the top, but you must recognize it as a shortcut. What you should NOT do is call for help and assert that you know where the issue is because it’s the “only thing that changed.” Also, if you are asking for help on how to troubleshoot the issue, you should NOT skip suggested steps with a response like “The issue couldn’t be there because that hasn’t changed.” Even worse is inventing possible changes and blaming the issue on them. “My email client must have upgraded last night.” You’d be surprised how often people blame issues on events that didn’t even happen.
Here at Untangle, we help customers troubleshoot all kinds of network/internet/computer issues. Please realize that if you overuse the “What’s changed?” technique, it can actually make it harder for us to help you because it means our first task is to disavow you of the idea that you already have the problem isolated to a specific component. This can sometimes be harder than troubleshooting the problem itself!