Nice article, thanks. I thought this sort of problem-solving approach was second nature to engineers, but maybe I am mistaken. I was raised by a medical professional, so maybe the DDx rubbed off on me when I was a child.
What happens when the patient gets better before the doctor finishes the diagnosis? Then the doctor gets paid, anyway. In engineering, we call this an intermittent problem, which can be much more difficult to diagnose. How about writing an article about this sort of diagnosis? Customers and Management don't think highly of the engineer when the problem comes and goes.
Differential analysis is used in management and accounting as well, sometimes to find errors.
Thanks Dave for such an informative post , i totally agree with the analysis method that you have mentioned i also used to follow almost the same method of technical analysis when was working inthe engineering department .First of all we used to consider the issue that customer facing , then we try to dig out the reasons for the issues and comparing how exactly the device should work if it was working properly then testing all the possible reasons by trial and error method .Hence almost in all technical departments the same method of analysis is being followed .
When I first read the title I though this couldn't be possible. Turns out I was right, as I can conclude the same after reading the piece. However, even though the title is not right, the content is spot on. As engineers, we love to dig into the tests directly and none or very little consideration is ever given to the 'medical history' of the part we are diagnosing.
I agree. The methods described in this article is exactly the steps I used when doing a Root Cause Analysis on Electrical-Electronics Systems. A key item to this method is documentation. Without documentation, the analysis activity becomes quite difficult to initiate because of the lack of information to investigate/research. The more information gather, less chance of going down a rathole trying to resolve the problem. Very nice article indeed.
Good point, Chuck. I'm not familiar with the horses vs. zebras quote. Is that saying that it's more likely to be horses than zebras?
Talking about hoof beats. I was in southern New Mexico last week and someone was a few minutes late to a meeting because a heard of wild horses crossed the highway and he had to wait for them to pass. It's still the wild west out here.
I like the saying, "When you hear hoof beats, think horses, not zebras." It could apply to a lot of areas of life, not just engineering. But I think it's a great way of saying, "Consider the most obvious problems first." Nice article.
Nice article, Dave. It sums up very methodically, what engineering and evaluation is all about. It almost could be the "pilot" article for Sherlock Ohms. Maybe at least it could be re-printed as an introduction to engineering, perhaps on the inside cover of a curriculum syllabus. Sums it all up quite nicely.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.