Toasters and troubleshooting

Stuff breaks.

Then, somebody comes to fix it and others are thankful. Perhaps thankful enough to give you a raise, if the thing that got fixed was really important. As such, having a good approach to troubleshooting is an important aspect to any engineering career (and lots of other careers for that matter).

As I outline in my series on Troubleshooting Techniques, the first set of steps in any troubleshooting session should be:

1. Were the set up instructions followed correctly (and, by extension, are those instructions themselves correct)?
2. Is the problem happening in all instances of this thing thats broken or is it only one instance?
3. What changed recently?

In most cases, that'll eliminate the easy fixes and leave you with more advanced techniques to try. In What is broken versus what isn't?, I outline a couple different ways to get into a deeper mode of troubleshooting by thinking about a system holistically:

"For example, suppose your device is a toaster. The first step in its operation is to plug it in. When you do that, can you verify that the unit is receiving electricity, perhaps through some indicator light? If so, then see if a piece of bread will fit correctly in the slots. Assuming that works, will the lever depress and drop the bread in the slots properly? Does that cause the coils to heat up? Does adjusting the darkness knob alter the amount of time that the bread stays in the slots and the coils stay hot as you might expect? When the timer is up, does the bread pop up out of the slots and do the coils cool down? These are the basic steps of toaster operation and walking through them, verifying the expected results along the way, gives a more granular look at the problem. You can discover what is working and what is not, allowing you to focus your efforts on a lower level of investigation."

There is a flip side of thinking about the operation start to finish and instead think about it i functional layers, which the article goes into after the quoted material above. Regardless of which way you choose to think about your broken system, have an analytic approach to testing out the subsystems. In complex troubleshooting situations, knowing what isn't broken can save you time and help you reduce the scope of your search for the real root of what is causing the problem.

 Was that interesting or helpful? Consider subscribing:  by reader  or   by Email