Richard Feynman, the Challenger, and Engineering

An anonymous reader writes "When Richard Feynman investigated the Challenger disaster as a member of the Rogers Commission, he issued a scathing report containing brilliant, insightful commentary on the nature of engineering. This short essay relates Feynman's commentary to modern software development."

Re:External Pressures Ruin Engineering

[Anonymous Coward]

And there's a whole slough of them I studied in college:

Yeah, I went to college at Wikipedia too. Remember when they upset Flickr in the Website Bowl?

Anyway, given that your list of "engineering failures" from the last century and a half, most of which weren't obviously predictable without hindsight, is shorter than the bug list in even a simple piece of typical software, I'm having trouble seeing where you get "Cut corners, often" from.

Tag on to a famous essay...

[sphealey]

(I will refrain from a four-step Profit post). Standard technique: latch on to an essay by a brilliant and insightful person. Extend the insights of that person slightly into a different field with usual compare-and-contrast, brand-extension writing techniques. Claim that resulting essay (and self) are as insightful as the original essayist.

It doesn't work 99.994% of the time, generally because very few people are as insightful as the original brilliant person.

sPh

Re:External Pressures Ruin Engineering

[Protonk]

There are other disasters that don't stem from the profit motive:

Loss of the USS Thresher during initial sea trials.

Steam Line Rupture on the USS Iwo Jima.

Both of those were caused by engineering (the first) or procurement faults.

The thresher was lost with all hands due to (among other things) a failure in modeling the high pressure air system and inappropriate welds on seawater systems.

The Iwo Jima suffered a steam line rupture that killed a few guys because the wrong material was used on a high pres/temp steam line.

Neither of these were for profit ventures. Both were preventable.

Re:Tag on to a famous essay...

[pilgrim23]

good point. I would suggest reading up on Dr Feynman as a precursor. Or, for those who prefer the flickering screen; there are several video interviews with the great man. One from Horizon called "The Pleasure of Finding Out" is VERY watchable. Also his book "Surely You're Joking Mr Feynman" is a hoot! Highly recomended. Richard Feynman is one of the greatest safe crackers who ever lived and in the top 10 of minds of the 20th Century.

Surely You're Joking

[Yoweigh116]

Offtopic, but I highly recommend Surely You're Joking, Mr. Feynman [amazon.com], the autobiography he narrated on his deathbed. It's got some great stories in it, like when he surreptitiously went around picking locks at Los Alamos or his personal recollections of the Trinity nuclear tests.

Re:External Pressures Ruin Engineering

[Sanat]

I stayed at this Hyatt over several different weekends while there was dancing and music on the ground floor. What would happen is that several individuals would get the walkways to start swaying and then reinforce the sway by shifting their bodies at the right instant causing additional sway from the positive feedback. it was not unusual to experience 3 to 4 inches of sway.

Although this swaying is not normally mentioned in the articles about the construction of the Hyatt, it went a long way towards weakening and stressing the connectors supporting the floors.

Two of my friends were dancing on the floor when the walkways gave way and both were killed.

 

Re:External Pressures Ruin Engineering

[MightyYar]

Same thing happened with the Citibank building in NYC - fortunately that error was caught by a student studying the plans!

As a software quality professional...

[gosand]

I've been in software quality and testing for 14 years. I've worked at very large corporations as well as startups. There is a WIDE gap in software development process in our industry. Many people like to call themselves software engineers when they are developers. There is a huge difference. Engineering is a discipline that follows well-defined rules, and it usually takes time. But I think the very important thing to point out is that some software requires engineering - other software does not. If I go into a startup company that is trying to develop a blog/wiki site and try to implement a NASA-like software development methodology, they will fail. Likewise, software to control a heart monitor should be engineered and closely controlled. Sometimes quality and perfection is the goal, other times it might be time-to-market that is critical. You have to fit the process to your business. A bridge is a bridge, and they should all be engineered pretty much in the same way. You can't say the same thing about software.

I think that this is a very key point to software development. I have seen companies who spent entirely too much time and money trying to eliminate all defects from their software when it wasn't the critical part of their business. Yes, we should always strive to eliminate defects, but you can't get them all. You have to know when to pick your battles, and when to accept the risks. If we're talking about life-or-death software, or security, or other very critical things - you need to focus on those.

There's a grid I have seen used that is a great tool when doing projects.
Schedule, Cost, Quality, Scope.
1 can be optimized, 1 is a constraint, and the other 2 you have to accept. Period. It is a more useful version of the "fast, good, cheap - pick two"

Re:Yeah, BUT...

[TobyRush]

I had never heard of Dresden Codak before this post but am now getting hooked while going through the archive. I think it's hilarious, but then I grew up in Los Alamos...

The linked comic is funny in a postmodern way (wondertwins vs. historical quantum theory) and the art is fantastic. A lot better than I could ever do.

One of the first things a new staff member does

[wannabegeek2]

I work in the aerospace industry, specifically an airline, as a manager of an Engineering subgroup. (if "manage" is what you call what I do)

One of the first things I have a new hire do is read Feynman's appendix to the Challenger Report. Primarily to instill a respect for dealing with data, not desires or pressures, and to (re)enforce the concept that "it worked last time", does NOT make it right or safe to do the same thing again.

The pressure / desire from above or parallel organizations within the company is constant, and usually precipitated by the latest operational interruption. All to frequently the refrain is along the lines of "but last time you authored a deviation, this is only a little bit more". When I feel the pressure is starting to cause situational ethics creep, I pull out Feynman's appendix, and read it myself, or have the affected person on my staff read it.

It is amazing how effective it is in restoring sanity, and a healthy respect for the ability of the hardware to kill you (and / or your customers).

Richard Feynman gave many things to this world, and especially certain segments of it. It's my opinion however that one of his best and most unsung gifts was the Challenger Report Appendix. It should be required reading for ANYONE who will ever touch or direct action on hardware that could even remotely present a potential for injury or death.

The message was not rocket science, but as the Columbia accident proved the rocket scientists still can't get it right.

Re:External Pressures Ruin Engineering

[Protonk]

It's not a random assertion at all. It's a foundation of economics. the world is full of information particular to place and time, on other words, the nitty-gritty. If you were to make a statistical model of part of the world, that stuff would get buried in the "other" term. Unfortunately, where there is a lot of "other" it becomes hard to model. Take for instance, who to give cars to. Should I have a survey and have the outcome determines who gets the car? Should I give the car to someone who needs it the most or will use it the most effectively? How do I judge that? how do I stop people from lying to me? I could, alternately, just sell the car to someone for an agreed upon price. That means I learn at least how much it is worth to them (it may be worth more) and the car goes somewhere. Prices transmit information and preferences better than any 5 year plan or government study. Sometimes markets have failures and those need to be dealt with, but that is not what I am talking about.

Re:External Pressures Ruin Engineering

[Neanderthal Ninny]

Threading also takes material from the total material and improper threading will cause fissures in the material which under stress cause failure of material.
This was a combination failure. Like most failures it requires many things to come into alignment before the disaster occurs. The Space Shuttle and Sky Bridge did fail because of one thing, but several factors that came together that occurred simultaneously then this disaster occurred. If any one of these factors where to be mitigated or removed then this disaster will not occur or if any did happen then there will be a recoverable situation.
My friend when I was in the US Air Force, Lt Col Ellison Onizuka, died in the Challenger disaster and I took that more than anything else. I was just a 1st Lt when that occurred and we where the only few Asians as officers at Edwards AFB. I remember learning that management at NASA, Morton-Thiokol, and other contractors okaying the flight even though they where outside the known parameters. Richard Feynman best experiment in the hearings was putting a piece of O-ring material in to cup of ice water and the O-ring material was brittle. I have since taken a Richard Feynman view of the of the world and now work in research lab where critical thinking is in order all of the time and top down management is a joke. We laugh at Dilbert who view top down management in the same way but in more humorous light. However when it comes to lives we need to mitigate or remove management from putting pressure on engineering or any other person so management can "look good" rather than the safely of people.