Is It Plugged In?

More often than not, when I would mention to someone that I was working on a book about troubleshooting, their eyes would light up and they’d blurt out:

Oh, I know about that! “Is it plugged in?” Right?!

This kept happening. Soon, I realized that I was writing about a topic with universal appeal. Machines are everywhere in modern life and we rely on them for so many things. Who hasn’t had a “I forgot to plug it in” moment in their life?

Humans are natural troubleshooters; anyone who is more than a few years old is experienced in the art. Think of all the things, both large and small, that you’ve fixed in your lifetime. Another aspect I liked about people shouting out “Is it plugged in?” was the implication that the cause of most failures was something simple. Experience says they’re right! If we were to scientifically graph how most problems are fixed, I think we would find:

One of the goals of my writing is to acquaint you with the full range of possibilities for failures and solutions. Who knows, maybe some day you will encounter a problem that requires (metaphorical) Unicorn Horn Dust. I’ve definitely seen some weird things in the troubleshooting trenches. However, experience says you’ll probably be spending most of your time on the left hand side of the graph, in the midst of solutions like plugging things in, adding gas, and rebooting. The seasoned professional troubleshooter will benefit from a periodic reminder of how often the solution is something simple. That’s me: my mind loves to entertain fantastic and novel possibilities that fit the data. On the other hand, those new to the game will benefit from having their horizons opened to the possibilities of subtle and complicated failure scenarios.

Prerequisites For Operation

Given its popularity, I was bound to address troubleshooting’s most famous question: “Is it plugged in?” The question, and brilliant associated solution: “Plug it in!,” is an example of a broader principle called “prerequisites for operation.” Every system has a context in which it functions. This includes the conditions required for it to work: the list of everything that has to be “right” and present (as well as absent conditions, as you’ll see later). This list can be very long and we usually aren’t aware of just how many things are needed for a system to operate. Frequently, it’s only when things break down that we first become aware of the dependencies implicit in the use of a given machine.

Take a gas-powered motorcycle and consider for a moment some of these hidden prerequisites. One dependency you may never have considered is: oxygen. That’s right, your typical petroleum-powered engine relies on having this atmospheric gas present in abundance to mix with fuel for combustion. If you shipped your Ducati to the Moon, it’s not going to work. That’s okay, you can still lean up against it, smoking a cigarette, trying to look cool. Oh no, cigarettes won’t work there either! Also, imagine if there were no gas stations. That would severely limit your commuting and road trip options, right? You’ve probably never thought about it until now, but an abundance of oxygen and gas stations allow a motorcycle to operate and be useful.

Oxygen and gas stations are ubiquitous over most of the world (at least the part where you’d typically drive a motorcycle), so you’re probably not going to find them listed as “needed” in the owner’s manual. My point is that the missing dependency that is causing a failure may not be documented. This is especially true for any custom-made system, where you can create an entirely unique web of dependencies from the parts you cobble together (e.g., a server farm or an oil refinery). In “The Order of Things” I outlined a strategy for reducing complexity by disabling subsystems. This is the other side of the coin: there may be a minimum level of complexity needed for the system to function!

Do I Need Any Others When I’ve Got This One?

At first glance, the strategy of fulfilling prerequisites seems like a promising candidate for The One. I’m talking about a singular strategy that you can use to solve any troubleshooting problem. Indeed, you can imagine having a List of Everything That Must Be Right, Present and Absent for a particular system. You could then methodically go through this list, line-by-line, to make the machine conform to the specification. It would be beautiful: there would no longer be any mystery to the troubleshooting process and fixing things would always be a certainty. Great! I’ll just put my feet up and take a nap while you write up that list…

Done yet? Unfortunately, such a document can’t exist as it would have to cover an infinite number of possibilities that couldn’t possibly be anticipated. Ducatis on the Moon are just the tip of the iceberg for how machines will get deployed in scenarios that designers, engineers, and technical writers can’t anticipate.

The “must be absent” portion of the list is where the problem of describing operating conditions becomes truly infinite. You may have seen an example of negative prerequisites in an operator’s manual when it says something like: “not to be immersed in water.” That’s right, in addition to things that are required, many devices need things to be absent to operate properly. Will a particular machine work when submerged in water or covered in peanut butter or placed in a sealed room filled with helium or launched into outer space or heated to 1000° C…? Each of these operational scenarios could be individually tested and documented (some at great expense) but you can begin to see that it would be impossible to cover them all in our ideal troubleshooting guide.

Back To Reality

Beyond the theoretical problems described above, where does the “prerequisites for operation” strategy rank in the real world? My experience is that the effectiveness of this strategy has a big front-loaded payoff (when it works). Up front, merely asking the question “What is needed for this machine to operate?” will uncover things like unplugged power plugs and empty gas tanks. Also, the manufacturer may have given you a list of prerequisites in their product documentation. Given their much deeper experience with a machine through the phases of design, testing, and support, a manufacturer’s guidance on matters of prerequisites are usually solid gold.

After that, the efficient discovery of information about failures seems best left to other strategies, versus trying to dream up Everything That Must Be Right, Present and Absent. Life’s too short to go that route!

References:

• Header image: “Guitar wire in black and white”. Juan Di Nella, photographer. Retrieved from Unsplash, https://unsplash.com/photos/OUgLA2unwtg.