Evidently your boss was made manager because he was incompetent at engineering. ;-)
A perfect example of the first rule of debugging... never assume you *know* what the problem is until you've actually fixed it!
I like this story because it resonates with many EE, since it describes many projects where imaginary ghosts were chased because those “were the likely problems observed previously”. Tradition permeates in many forms.
The system being "a bit more accurate" was due to using a 12 bit A/D converter instead of a 10 bit one, and using kelvin connections for the resistance measurements, which added a bit of stability. Also, I used a power supply that was good for about 50% more current than I needed. The "big deal" is that products for the industrial market, unlike consumer electronics, must stay within specifications for over a year, without pausing for recalibration. The extra money spent on providing a bit better accuracy was less than $200, I believe, which is less than the cost of one warranty service call to re-calibrate a machine.
Providing the additional accuracy is sometimes not only handy, but also vital. Another time, later on in my career, we built a set of test machines for a customer who had refused to accept a set of machines for the same application, which had been built by another company. Those machines "had come fairly close to meeting some of the specifications" was the way it was explained to me. But those machines were still sitting on the builders loading dock, not paid for, when our machines were installed, running production, and paid for in full.
When I hear of stories about a VIP babysitting an engineer I remember a story Red Adair told during a Congressional hearing. It seems Mr. Adair was called to put out an oil well fire on an oil platform in the Gulf of Mexico. Out there to "help" him was a person from the EPA who was telling Adair what he could not do because it might cause pollution. Never mind that the well was on fire, spewing oil to feed the fire, causing further pollution, and costing money. No, you have to be careful no to cause any pollution. Adair turned to the guy and said, "Since you know so much more about putting out oil well fires than I do, I'll just get out of your way." And then he left the platform in the capable hands of the helper. Well, Adair was called back the next day and the helper was gone. Adair had made his point to Congress quite effectively.
Salio, I think you're being a bit critical...if (eg) the client only needed 6-bit ADC resolution and you've got an 8-bit ADC, why not use it?
And if you have not yet had the pleasure of having a manager with just enough technical knowledge to be dangerous (and annoying) then you are bloody lucky!
There are several "amusing" facets to this story worth a comment.
First, the manager that "knew" what was wrong, then blamed the engineer for not finding what it really was sooner.
Second, the all too common scenario of the VP of Sales (or other executive) that thinks that babysitting an engineer somehow makes things happen faster.
Third, the overspecification achieved versus what was requested. I suspect if the VP of sales had overheard that, he probably would have had a fit because the product was now priced too low for its superior specs!
Karen I agree with you.
William what you did I think was just barely meeting what the client had asked for. Was it not in the specs that the testing will be done with both of the stations running?
I think we as engineers should let our clients tell us that we have met exceeded their expectations instead of us claiming such. I think it sounds so much better when a client calls up one's boss to say that so and so went above and beyond to finish the job.
Maybe your manager who is dissappointed in you should next time maybe not jump the gun.
Were the units tested in paralled prior to the client seeing the test? If not, how come?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.