Nerd Guru

Because technical people need good soft skills to get ahead.

Thursday, August 16, 2007

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

posted by Pete Johnson @ 9:22 AM   2 comments


At 4:18 PM, Anonymous Matt Nawrot said...

Thank you for taking the time to post this troubleshooting guide. I found it much more in depth than any guide which I have read in several textbooks. Specifically, the steps in your guide involve communicating with the 'customer', which is absent in many of the guides I have read in my textbooks. In addition, your guide puts the 'easy solution' steps first, where they should be. I would recommend this troubleshooting guide as the best I seen. Thanks again

At 7:44 PM, Blogger Pete Johnson said...

Wow, Matt, thanks for the kind words!

Believe me, those tips are a result of many years of learning from mistakes. I'm glad you got something out of it and hope you become a regular!


Post a Comment

   Subscribe to comments in a reader

   Subscribe to comments by Email

<< Home

Technology Blogs - Blog Top Sites