The uncertainty principle

3/24/2011 2:25 PM EDT

Please forgive the following snide comment: "What? Are there known unknowns?"
OK, I'm over it! Seriously - my experience has been that understanding basic concepts and seeing those concepts in action, or better yet, working with them in a "real world" manner will probably be of greatest benefit. Theoretical exercises certainly can work to demonstrate the fundamental concepts, but the real world is full of nth-order effects and dependencies that often seem to contradict theory, because the theoretical model is incomplete or incorrect. Read National Semi guru Bob Pease's work if you want to know how often theory (specifically SPICE models and simulation) do not match real world fact.

3/25/2011 2:09 AM EDT

Models are just that - models. It is kind of like going into war battles per the model(s) on the planning room table, and wondering why it didn't actually work out the way it was planned. Not only is the real world different than models, real people in real time/world situations don't give a damn about a model when reality is staring them in the face.

3/25/2011 12:31 PM EDT

I should have mentioned that story that emerged this week as part of the BP oil-leak investigation. The well apparently has a device whose sole purpose is to clamp the pipe shut in case of an emergency. The explosion shifted the pipe slightly so that the two opposing parts of the clamp couldn't form a tight fit.

You'd think they would have factored in potential misalignment of the pipe in an explosion, but maybe not.

To KD's point, models are models. And I supposed if we could factor in all the potential outcomes, we'd never move forward for fear of catastophe.

3/26/2011 9:50 AM EDT

To paraphrase Bob Pease, the results can never be more accurate than the model used. An incomplete model can produce very pretty results that are very wrong, although they may appear to be correct over some small range. With the failed blowout preventer on the oil well, the device is supposed to be locked onto the well so that no shift is possible.
As for taking control of the big screen, would you want that capability to fall into the hands of those internet folks trying to sell us viagra? Just think about that "unintended consequence."

3/26/2011 4:15 PM EDT

I just checked out the 'Aerostatic Flutter' link.
Cool stuff! Though the solution that was presented seemed too simplistic for all the aeronautical engineers to have not considered as yet. I would love to hear what NASA had to say about their models.

3/27/2011 2:20 AM EDT

NASA can model, simulate, make, launch the Messenger satellite to orbit mercury after making it travel for more than 6 years and billions of miles . That disproves the uncertainty principle. Uncertainty of performance, uncertainty of quality etc is actually built by the product designer or implementer by overlooking some aspects. That 'let-go' thing is yhe root cause of all those uncertainties. In case of a mission like sending the satellite to Mercury such 'let-go' attitude is not tolerated and hence the project becomes successful.

3/27/2011 8:12 PM EDT

In a similar light, the less I know about the origin of Kopi Luwak amd Chorizo, the better I enjoy my breakfast with my favorites: scramble eggs and coffee. One has to enjoy the result that proven good sources of nurishment and flavor. By the same token, one has to understand at a high-level the implications of complex organic chemistry, and know alergy potential, the same way that basic modeling provides an estimate. Not necessarily a detailed and inclusive analysis of significant n-th order effects. Just an observation.

3/27/2011 10:37 PM EDT

Uncertainty in design is inversely proportional to time and money spent the original design as well as the design of the backup systems. There is an included factor that prevents uncertainty from actually reaching zero.

In theory, the more mission critical / life-critical a system is, the more time and money it gets put on redundancy and back-up systems. Reality doesn't always match up with theory in this case either though.

3/28/2011 2:11 PM EDT

Check out this book if you can find it:
"Inviting Disaster" by James R Chiles pub HarperCollins ISBN 0-06-662081-3

3/30/2011 8:31 AM EDT

Without models, you can't design extremely complex machinery in the first place. The trick is to know when to leave the model behind and confront reality directly. Don't blame the models nor the modeling when it's human judgment that's often the root cause of a problem.

On books, first read C. Perrow's book Normal Accidents, which points out the commonalities (and seemingly near-inevitability) of accidents such as nuclear plants, but then read Chiles' book, which also points out that for every Big Accident, there are ten near-misses that would have also been Big Accidents but for the timely intervention of some enlightened person who saw what was happening in time to take action.

3/30/2011 8:25 PM EDT

@crwilliams and @rpcy... I would love it if you'd write up reviews of the books you referenced. They sound like worthy additions to the Engineer's Bookshelf section.

If you're game, just send me your review to my email and i'll post straight away: brian.fuller@ubm.com.

Thanks for the comments!

3/31/2011 6:54 AM EDT

keep trying and trying and learning new stuffs. But how much you learn there will be some unknowns and life is better like that.

4/1/2011 5:21 PM EDT

What isn't mentioned here is reasoning with uncertainty. Often models don't include it either. The simplest model in the world can be used if it can tell you the boundaries of its accuracy. This is one of the key issues with SPICE. It often uses approximations. If instead of reporting them as gospel, it would tell you the answer was between two limits and always be right on that account, you could then decide if that was an adequate answer or more investigation was needed.

And to NevadaDave, there are known limits to existing knowledge and models. When we go outside those, we know that we are in unknown territory.

4/7/2011 1:34 PM EDT

This thread takes on new meaning in the wake of the failure of the fuselage aboard the Southwest Airlines flight.

The USA Today article states the obvious: "Holes in planes rare but pose deadly risk"

http://travel.usatoday.com/flights/story/2011/04/Jet-metal-fatigue-a-rare-risk/45808638/1

I have to think, though, that as circuits shrink and get weaved into more and more materials, that our ability to be alerted to material stress and the like through sensors increases. That's a nice insurance policy when modeling falls short.

4/27/2011 3:40 AM EDT

I have a feeling that simple designs are not possible or allowed anymore. It has to be cramped with features, applications, extensions and connections that make them unnecessary complex. If I look to software most people rarely use 15% of the capabilities of f.i. word processors. I know that in the name of progress and profit a lot of the complexity is actually a need that is artificially created by clever campaigns from manufactures and not consumer demanded. And ther is also the learning curve for each product that becomes steeper when getting older. There is no relation anymore with the look and feel of the old product you replaced (f.i. Cell phones) A more baffling evolution is that simple products become more expensive due to there limited market potential (f.i. Cell phones for elderly people) The “Back to basics” although a good slogan has sometimes a strange side effect.

9/19/2011 5:45 PM EDT

Better tools. That is how we have managed each technological step. As industry became dependent on electricity, no-one said 'Let's a'make all our manufacuring systems more fragile', they said 'Look how much more productive we are with this new machinery!' Then, by trial and error, with factories failing every now and then, tools were developed to make reliable electricity generation, monitoring, and usage.
Whether this attitude will work as we abstract our software-dependent systems still further from our caveman roots, remains to be seen. But I suspect that the best use of computer power will be found to be in software manufacture, in removing the human element from every part of the process that doesn't need it.
But that initiative won't come from the software community, will it?