Contact and Coil | Nearly In Control



The “Almost There” Paradox

We’re all probably familiar with the idea that it takes half the time to get to 90% done and the other half to finish the last 10%. This is a staple of project management.

I think there’s actually a narrower scope of really dangerous solutions that you only become familiar with after you experience it. There’s a whole set of problems where the obvious solution gets you 95 to 98% of the way to your performance spec really quickly, but is almost impossible to reach 100% by incremental improvements. The reason I say they’re dangerous is because the feeling of being “almost there” prevents you from going back to the drawing board and coming up with a completely parallel solution.

I can remember a machine vision job from years ago where the spec was “100% read rate”. I only got it to about 94%, and someone else gave it a try. He got it up over 96%, but 100% was out of reach given the technology we had.

Experiences like that make you conservative. Now I unconsciously filter possible solutions by their apparent “flakiness”. I’m much more likely to add an extra prox to a solution to verify a position than to rely on timers or other kinds of internal state, because the latter are more prone to failure during system starts and stops. I press for mechanical changes when I used to bend under the pressure to “fix it in software”.

Still, you have to be careful. Its easy to discount alternatives just because they bear some passing resemblance to a bad experience you had before. You have to keep re-checking your assumptions. Unfortunately, rapid prototyping usually fails to uncover the “almost there” situation I’m talking about. If you prototype something up fast, and it works in 97% of your lab tests, you’ll probably think you have a “proof of concept”, and go forward with it.

The best way to test new solutions is to put them into production on a low risk system. If you’re an integrator, this means having a really good relationship with your customer (chances are you need their equipment to run your tests). If you work for a manufacturer, you can usually find some out-of-the-way machine to test on before you go all-in.



  • Ken McLaughlin · August 19, 2010 at 1:01 pm

    I agree 100%.

    It’s really easy to make something work 50 or 100 times in the lab, but what does that equate to in real production time? Running 2000 twinkies through a prototype in a lab may sound like a lot, but if the line rate is 200 twinkies per minute, it’s only 10 minutes worth of production. To get a 1-shift equivalent for a week you need to run 96000… …not practical in a lab to do.

    To get real OEE and performance you need to run real significant numbers to get real data.

  • Jeff M · August 19, 2010 at 1:15 pm

    Very good point Scott. I’m a regular victim (or perpetrator?) of this scenario (though not related to industrial automation per se). I find that this happens often due to feeling too pressed for time/budget to go back and re-think the solution. It can be hard to justify to the people in charge that we need time to ‘re-think’ a little. They would usually prefer to just squeeze a little more juice out of the lemon.

  • Author comment by Scott Whitlock · August 19, 2010 at 2:23 pm

    Good point Ken. It makes you wonder how NASA manages to land *any* landers on Mars… it’s not like you can try that too many times. 🙂

Leave a Reply



Theme Design by