Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

We talk with electrical engineer Bob Schmidt about troubleshooting in this episode of The Engineering Commons podcast.

• Please help us improve the podcast by filling out our 2014 Listener Survey!
• Adam, Brian and Jeff agree that troubleshooting computer software problems can be a frustrating process.
• Our guest for this episode is Bob Schmidt, an electrical engineer with 40+ years of experience dealing with software, hardware, and system design.
• Bob obtained an FCC first-class radiotelephone operator license at the age of eighteen.
• A Motorola 6800 microprocessor provided the computational power for Bob’s first computer, which had 512 bytes of memory.
• Bob got interested in troubleshooting when he realized he was being specifically paid to deal with problems.
• We often learn useful lessons through “parables of problem solving.”
• “The Dog Barks When the Phone Rings: An Engineer’s Guide to Solving Problems” is Bob’s new book about troubleshooting. Look for the second edition of the book, which will be published any day now!
• Another troubleshooting reference is David Agans’ book, “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.”
• Bob Pease’s book, “Troubleshooting Analog Circuits,” is a problem-solving guide related specifically to electronics.
• The “five questions” approach that Bob advocates for problem-solving involves asking:
  1. What do you know?
  2. What are the rules?
  3. What don’t you know?
  4. How can you find out the stuff you don’t know?
  5. How do you know when you are ready to solve; or have you already solved the problem?
• It’s important to write down what you know when beginning to troubleshoot a problem.
• Our guest feels that clear communication is an important element of the problem-solving process.
• Carmen references one of Bob’s blog posts, “What Customers Don’t Understand.”
• We must be attentive to the constraints of people, time, money and results when addressing the customer’s problems.
• Henry Petroski’s book, “To Engineer Is Human: The Role of Failure in Successful Design,” discusses what can go wrong in engineering projects.
• In a 2010 presentation for the National Book Festival, Dr. Petroski talked about how the sciences and engineering are treated when successes and failures occur.
• Our guest feels that studying the designs of other engineers is a great way to get an intuitive feel for potential problems.
• Carmen references a Jim Williams tale about design titled “The Zoo Circuit: History, Mistakes, and Some Monkeys Design a Circuit.” This case study is told as a chapter in the book “Analog Circuit Design: Art, Science and Personalities.”
• Not all information on the internet is reliable, as Bob discussed in his recent blog post, “The C.R.A.P. Test.”
• It makes sense to ask experts for help in problem-solving, but one has to be cognizant of other demands on the expert’s time and attention.
• An engineer’s physical senses can be quite useful in troubleshooting problems.
• “Debug by division,” or “divide and conquer,” is a useful methodology for solving problems.
• Adam discusses how the debug process is applied in road building.
• Watching others apply the “debug by division” process is useful means for learning the methodology.
• Bob’s book offers a few “warnings” that should be heeded if you think you’ve successfully solved a problem:
  1. Correlation is not causation.
  2. Your theory of causation had better show good correlation in your experiments.
  3. There might be more than one correct answer.
  4. Undo your fix and check to see if the problem returns.
  5. There can be multiple paths to good solutions. Your way is not the only way.
  6. Never allow a defect or problem report to go by without documenting and fixing that problem.
• Additional “challenge” questions that one might ask about a possible solution include:
  1. How did other people solve problems similar to this problem in the past?
  2. Good writers of design are good readers of other people’s designs. Are you a good reader?
  3. Could it ever have worked that way?
  4. Does it work that way now?
  5. Are you suffering from optimism bias?
  6. How complete are your checklists?
  7. Are you doing big debug or little debug?
• Our guest feels that engineering schools should emphasize troubleshooting as an integral element of the design process.
• Bob can be found on the web at PrettyGoodProblemSolver.com.

Thanks to César Astudillo for the photograph titled “Troubleshooting.” Podcast theme music provided by Paul Stevenson.