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."

Comments

Huh?

[arizwebfoot]

I scanned TFA and I'm not sure he has a clue about Linux, IMHO.

Re:Huh?

[Workaphobia]

...

What are you talking about? He mentions Linux twice on that page, once in the context of how he's handling the slashdotting, and again in the main article as an offhand example to convey the breadth of his discussion. Your non sequitur is almost equivalent to "Nice argument, but you obviously don't have a clue about yellow elephants."

External Pressures Ruin Engineering

[eldavojohn]

I'm a software developer. I would like to think of myself as an engineer but to me that's a higher title that belongs to people who actually engineer original ideas.

The problem with the shuttle disaster (both of them, really) is external pressures that are not in anyway at all scientific. The pressure from your manager at Morton Thiokol to perform better, faster and cheaper. The pressure from the government to beat those damned ruskies into space at all costs.

So this is really a case of engineering ethics, when do you push back? As a software developer, I never push back. Me: "There's a bug that happens once every 1,000 uses of this web survey but it would take me a week to pin it down and fix it." My Boss: "Screw it--the user will blame that on the intarweb, just keep moving forward." But could I consciously say the same thing about a shuttle with people's lives at stake? No, I could not.

So when an engineer at Morton Thiokol said that they hadn't tested the O-Ring at that weather temperature that fateful day and that information was either not relayed or lost all the way up to the people at NASA who were about to launch--it wasn't a failure of engineering, it was a failure of ethics. External forces had mutated engineering into a liability, not an asset.

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

* Space Shuttle Columbia disaster (2003)
* Space Shuttle Challenger disaster (1986)
* Chernobyl disaster (1986)
* Bhopal disaster (1984)
* Kansas City Hyatt Regency walkway collapse (1981)
* Love Canal (1980), Lois Gibbs
* Three Mile Island accident (1979)
* Citigroup Center (1978), William LeMessurier
* Ford Pinto safety problems (1970s)
* Minamata disease (1908-1973)
* Chevrolet Corvair safety problems (1960s), Ralph Nader, and Unsafe at Any Speed
* Boston molasses disaster (1919)
* Quebec Bridge collapse (1907), Theodore Cooper
* Johnstown Flood (1889), South Fork Fishing and Hunting Club
* Tay Bridge Disaster (1879), Thomas Bouch, William Henry Barlow, and William Yolland
* Ashtabula River Railroad Disaster (1876), Amasa Stone So I agree with Feynman's comments in relationship to engineering and the further comments to software development. But I don't find them to be a fault in the nature of engineering, just a fault in our ethics. What does capitalism and competitiveness drive us to do? Cut corners, often.

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.

Re:External Pressures Ruin Engineering

[Rob T Firefly]

Well said. If I could mod you higher than 5, I would.

Re:External Pressures Ruin Engineering

[DBCubix]

The Kansas City Hyatt Regency walkway collapse was an engineering problem. The contractor asked to take a shortcut (instead of threading a nut up a three story threaded rod, they asked to cut the rod and offset it several inches) and the engineers rubber-stamped it without checking what the ramifications would be. The engineering part was not originally flawed, but it was when they approved the change order.

Re:External Pressures Ruin Engineering

[Vicious Penguin]

> What does capitalism and competitiveness drive us to do? Cut corners, often.

Maybe, but remember what your own example shows -> What is the cost/benefit of fixing/preventing an error? Is a week of debug time worth missing your target ship date? Maybe, maybe not - depends on the error.

A blanket indictment of capitalism is quite unfair. You would still have the same cost/benefit analysis regardless of economic system you toiled under.

Is is not possible to engineer against all eventualities; trying to do so will usually keep you from ever getting off the ground.

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:External Pressures Ruin Engineering

[SethHoyt]

Add the $15 billion federally funded Big Dig to the list of engineering disasters.

http://en.wikipedia.org/wiki/Big_Dig_ceiling_collapse

Re:External Pressures Ruin Engineering

[Yvanhoe]

There is a point you miss there I think. It is the top-to-bottom design philosophy vs the bottom-to-top. The first one gives objectives first then designs every part so that it fulfills the general objective. The latter focuses on designing simples elements and assemble them as more complex elements with defined capacities and known weaknesses.

This article states that the second approach is inherently better than the top-to-bottom approach. This is clearly an engineering problem. I am not sure I agree with the conclusions and acknowledge that most of the Challenger disaster was due to unwelcomed pressure, but I don't think you can dismiss the whole issue as not concerning engineering.

Re:External Pressures Ruin Engineering

[Protonk]

This is true to an extent, but safety concerns can and should be engineered for. You are absolutely right that there exists no direct corollary between software debugging for some non-critical application and meeting safety margins for a critical product. However some software IS critical. Flight software (This portion of Feynman's essay about NASA's flight software is amazing), software for hosptial applications (pharmacy, PCA's, microsurgery), ABS/suspension control software. Those are applications with VERY critical outcomes. Safety conerns need to be built in to the process.

But I do agree that tradeoffs occur under any system. Those tradeoffs just let us make better decisions under capitalism whereas we can't allow the information from those tradeoffs to inform us economically in a socialist system.

Re:External Pressures Ruin Engineering

[esocid]

Apparently you've never taken engineering ethics. The first class I had to take as a general engineering major. Needless to say, I changed majors but still got a hell of a lot out of that ethics class. The parent was right. These were all cases of cutting corners, either in terms of cost or time. Managers wanted it done quickly and cheaply, whether that meant mixing concrete improperly, or buying sub-par materials, or just ignoring what the engineers are telling them. It always came down to about 95% managerial and the rest engineering error.

Re:External Pressures Ruin Engineering

[Anonymous Coward]

But could I consciously say the same thing about a shuttle with people's lives at stake? No, I could not.

Absolutely.

Progress requires risk. The astronauts are aware of their risk, it's not a big deal.

Yes, it would be nice to take 500 years to flawlessly engineer a tool, but in reality, you don't have that long. Engineering is sometimes about making educated guesses in order to build something in a reasonable period of time, and you learn something from your errors. Obviously more commercial tools require more margin than more complicated ones - you expect more risk going to the moon than going to 7-11. (Oddly, there's probably more risk per mile going to 7-11, so the space engineers are doing a pretty decent job.)

The problem with the shuttles wasn't poor engineering - it was that when someone spotted an issue, that it was squelched. This is a social/management problem, not an engineering problem.

Re:External Pressures Ruin Engineering

[ChrisA90278]

I'm a software engineer too. However I've worked on projects where a software failure could get people killed or destroy hundreds of millions of dollors of "stuff". For example the software might be processing radar data inside a little gadget that flays at mach four and caries an explosive warhead. In those cases to don't just say "the user will blame the bug on The Internet" and let it go.

The thing with software is that it is such a wide field. If you are wrinting a web based survey program, so what if it crashes 0.5% of the time. But then if the software is the primary flight control for a large airliners loosing one to two hundred airplanes is unacceptable.

for the most part, from what I've seen critical software does in fact get enginered using prety good techiques. While, yes a lot of the web is coded by just some guy working under presure to get it done. So the point is you can't lump all software together.

With all the trouble the space shuttle has had, has anyone every blamed the on-board software? I don't think so. The shuttle is often used as an example of about the only way to write bug free software. It was very expanive and few progect will sppend that kind of money but that is what it takes.

Re:External Pressures Ruin Engineering

[somersault]

I'm a software developer. I would like to think of myself as an engineer but to me that's a higher title that belongs to people who actually engineer original ideas. Well I know I'm missing the point of your post with this, but a quick google comes up with this description of an engineer:

a person who uses scientific knowledge to solve practical problems I think your higher title should be an 'inventor'. Engineers are the guys that generally plod away using well tested mechanical or other scientific knowledge to get everyday jobs done (just like a software engineer really?). I work as IT support/coder for a bunch of engineers here and while they sometimes may be using old ideas in new ways, most of their work is just that plodding away using tried and tested methods, with occasional refinements in stuff like blade geometry for example (we do a lot of work with turbines). I think there is actually a lot more invention done in the field of software development than in engineering. Having said that, I studied 'Computer Science' and not 'Software Engineering', so apparently I'm a scientist :p

Re:External Pressures Ruin Engineering

[Knara]

Don't tell that to the "professional engineers", though. Their head will fly off if they're one of the 80% of those who think that "software engineer" is tantamount to blasphemy.

Re:External Pressures Ruin Engineering

[ccguy]

"There's a bug that happens once every 1,000 uses of this web survey but it would take me a week to pin it down and fix it."

How can you give a time frame for a non repeatable bug you still have to pin down? If you had a boss like mine you would be in trouble, because he would say "ok, fix it, I'll get you the time" and if a week later you don't deliver, he wouldn't be very understanding.

Re:External Pressures Ruin Engineering

[theskipper]

* Citigroup Center (1978), William LeMessurier

In fairness, the ethics involved in the initial "cost-savings" decisions should be separated from ethics of how the situation is handled after the problem is revealed.

It's pretty well documented that he exhibited uber-ethics by owning up to the engineering problem immediately after a student pointed out the miscalculations: http://en.wikipedia.org/wiki/William_LeMessurier. Point being, he could have just lawyered up but that's not how responsible engineers behave. There was also a Nova program years ago that documented the whole story.

Re:External Pressures Ruin Engineering

[Dan Posluns]

This is precisely why engineers in Canada have both a professional association and what was deemed to be a "suitably dignified" Ritual of the Calling of an Engineer that was devised by Rudyard Kipling in response to the Québec Bridge disaster in 1907 due to faulty engineering.

The purpose of the ritual is to establish the engineer's tri-fold obligation to society, their employer and themselves. The Iron Ring is the symbol and constant reminder of the engineer's obligation to society.

Software Engineers from any of the newly accredited B.Eng programmes in the discipline of Software go through the same ritual and are licensed under the same governing body.

Dan.

Re:External Pressures Ruin Engineering

[drinkypoo]

It seems like bottom-to-top engineering is the best way for an individual to work - they know what they're trying to accomplish and they're the one who understands where the rubber meets the road. Conversely, the top-to-bottom approach seems best suited to large teams, because it should lend itself to more compartmentalization of effort. But then, I'm not an expert on the subject, and life is often counterintuitive. Certainly, however, basically everything I write is bottom to top :)

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

[Anonymous Coward]

Do you stamp/sign every line of code you let go? Are you personally liable for anything you approve with your sign/stamp? If not, don't use the term professional engineer. If a "software engineer" screws up and is fire, they go somewhere else to work. If an engineer scews up and is fired, they most likely won't be able to find somewhere else to work in their field.

Re:External Pressures Ruin Engineering

[somersault]

I can think of some draftsmen that would probably have a chuckle at it, but a few of them have decent computer experience and would probably see my point if I talked about coding in terms of engineering. One of the guys used to work for Rolls Royce, he's our expert when it comes to the blade geometry stuff, and usually tells interesting stories of the olden days and him using FORTRAN and such :p Then there's my uncle who got a degree in Computer Science in the early 90s, but just recently finished a PhD in fluid dynamics.. Computing and Engineering both involve the same type of mindset IMO.. designing, implementing, bugfixing, etc

Re:External Pressures Ruin Engineering

[Knara]

Sure, and I'd agree with you, but I point you here (later in this very discussion) for an example of what I'm referring to.

Re:External Pressures Ruin Engineering

[Knara]

Oh, and this AC for that matter.

As if engineering didn't exist before someone made it an attainable certificate.

Re:External Pressures Ruin Engineering

[ceoyoyo]

That's the difference between an engineer and a not-engineer. Software developers are more like building contractors. You do what the boss says. The engineer, who's in charge of the job, or at least inspecting the job, is required, legally, to tell the bosses to screw off if they ask him to cut a corner that compromises safety. If he doesn't he's finished.

Re:External Pressures Ruin Engineering

[Omnifarious]

Blaming the shuttle disaster on capitalism is erroneous. I do not necessarily disagree with your assessment in general, but capitalism was not at fault in that particular instance. What was at fault was bureaucrats trying to look good to their superiors and present a positive public image at the cost of real engineering.

I would say that in general is the meta-problem, not capitalism. In its current form in the US capitalism has caused the existence of many large entities that use hierarchical systems of command and control. These hierarchical systems frequently make sub-optimal decisions because individual actors within the system act for their own benefit but against the benefit of the larger system they are a part of. Particularly egregious examples of this can be found, and they tend to be highlighted as aberrations, but they aren't. They are merely extrema of a problem that is widespread.

Bureaucracy in general serves to insulate actors from responsibility for the results of their actions. As I recall we didn't see any of the middle management of NASA held accountable for the disaster they caused by attempting to look good for their superiors and the public. And this failure of accountability is endemic to the kinds of hierarchical systems you see in most bureaucracies.

Re:External Pressures Ruin Engineering

[stubob]

I would argue that, strictly speaking, you're doing iterative top-down engineering. Bottom-up engineering would consist of creating the APIs, then fleshing out the functionality defined by the API. Integration of the small parts into a large application doesn't necessarily imply bottom-up.

Bottom-up: I will need a method to retrieve the data from the database.
Top-down: I need to retrieve data X from the database.

Since I blogged about this a bit ago, I'll post my own link:
http://stewartj76.blogspot.com/2008/01/theres-no-such-thing-as-bottom-up.html

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!

Re:External Pressures Ruin Engineering

[russotto]

The Kansas City Hyatt Regency walkway collapse was an engineering problem. The contractor asked to take a shortcut (instead of threading a nut up a three story threaded rod, they asked to cut the rod and offset it several inches) and the engineers rubber-stamped it without checking what the ramifications would be. The engineering part was not originally flawed, but it was when they approved the change order.

Right, except that the original design wouldn't have worked, as the integrity of the threads could not have been maintained during construction and thus the nut could not have been put on. So in software terms it was a last-minute patch to fix a show-stopper, which wasn't adequately unit-tested.

Re:External Pressures Ruin Engineering

[Radical Moderate]

I had a couple friends there too. One covered the story for AP--he was still in college, was huge break for him--the other worked at the Hyatt, hearing his story just about froze the blood in my veins. I'd never heard about the engineers OKing the design changes.

Re:External Pressures Ruin Engineering

[Anonymous Coward]

Give me the job security and the level of genuine authority that goes with the personal responsibility, please. Until that arrangement is available to professionals in the software development world, stop complaining that software engineers call themselves "engineers."

Re:External Pressures Ruin Engineering

[Tyberius]

Those tradeoffs just let us make better decisions under capitalism whereas we can't allow the information from those tradeoffs to inform us economically in a socialist system.

Maybe you "can't allow", but it is certainly possible:

&f($time) eq &f($money)

Unless in socialism you just have plenty more time.

Re:External Pressures Ruin Engineering

[Anonymous Coward]

I don't think you can necessarily say they weren't for profit ventures. At the high level, they definitely weren't, but at lower levels, they may have been.

I mean, I certainly can't say for certain that the contractors who built the Iwo Jima weren't "for profit", and, to be honest, I would expect that they would be operating for profit.

Re:External Pressures Ruin Engineering

[dubl-u]

So I agree with Feynman's comments in relationship to engineering and the further comments to software development. But I don't find them to be a fault in the nature of engineering, just a fault in our ethics. What does capitalism and competitiveness drive us to do? Cut corners, often.

Any approach to engineering that only works with uber-humans, rather than the regular ones we have to work with, strikes me as painfully naive. Much of engineering is about understanding and accepting the nature of the materials used. Surely we can do that not just with compounds and chips, but also with people?

If we know people will want to cut corners, we as engineers and developers need to make sure they cut the right corners. That's one of the things I love about short-cycle agile methods:

• If I complete some new feature every week in priority order, when we run out of time, what is left over is the lowest-priority features.
• If I start from day one with automated tests for everything, then I don't have to choose between quality and quantity: keeping quality up gives me the ability to produce greater quantities.
• If I do my work in such a way that they can change direction every week, then they can respond to and even outpace their competitors without compromising anything.

More importantly, I think we must learn to talk the language of managers, and to build strong relationships with them. When we see a problem that has serious implications, we need to be able to put it in business terms. Rather than saying that X is suboptimal or wrong, we should be able to say that it will result in lost sales or confused users.

And most importantly, we should stop offering people the option to build bug-ridden pieces of crap. That is frequently what people want in the short term, but never what they want in the long term. It's unprofessional, it harms relationships, and wrecks the image of our profession. That's not to say we should insist on gold-plating everything, pursuing technical perfection that has dubious real-world merits. But in the same way a licensed engineer would not see building a shoddy bridge as an option, we should stop treating buggy, low-quality software as the norm.

Re:External Pressures Ruin Engineering

[homey of my owney]

That might well be the case, but it doesn't really address what Feynman is saying. Yeah, there's plenty of examples as you say, but the point of TFA is that the whole top down approach is another whole area that leads to failure.

From personal experience, if you ever hear someone say "Our design will be a pristine waterfall..." don't walk, run.

Re:External Pressures Ruin Engineering

[uncqual]

Being able to say with any reasonable degree of confidence that a particular bug is encountered "once every 1,000 uses" implies that it's been encountered multiple times and hence is repeatable - just not yet reliably repeatable on a single test run. If only 1000 test iterations are run and one fails due to "a bug", it's really not possible to say much useful about the odds of the bug being encountered - with some degree of confidence perhaps one could say that it's probably encountered less often than one in every 20 uses, but it's also quite likely that it only occurs once every 50,000 uses.

If one has the knowledge to say with a a significant degree of confidence that a test fails due to a particular bug once every xxx test runs, they have some information. When combined with a good understanding of the code and test environment, this can be often used to make an educated guess as to how long it will likely take to identify the bug (and, perhaps, to fix it - although, until isolated and understood, this is more speculative). This information includes how many times the problem can be recreated in a given time period and the cost of that activity (assuming that recreation of the problem is necessary to gather more information) and the understanding of the code gives some reasonable professional insight into what additional diagnostics can be enabled or added and what the odds of those diagnostics perturbing the execution such that the problem is fully or partially masked.

For example, if a bug is encountered "randomly" every 1000 test runs, but a test run takes 100ms on a developer laptop, I'd expect that someone familiar with all the involved code would usually be able to identify the source of the problem in a fairly short time (usually well less than 1/2 a day). If, on the other hand, a test run takes 1 day on the only machine that's been built yet, the problem will probably need to be found by code inspection or by honing the tests to expose the problem much more frequently -- and this process is much more difficult to predict.

Perhaps you need to find a new boss - one that understands these things :)

Re:External Pressures Ruin Engineering

[ceoyoyo]

Come to Canada and take a four year software engineering program, then do your PEng. Now I'll resume complaining.

Re:External Pressures Ruin Engineering

[Brad Eleven]

Just because all of the ethics violations don't result in disaster doesn't mean that they're numerous. It's not the cutting of corners that causes the problem. It's cutting corners without communicating same.

So the general case is that of a software bug: Modifications introduced out of band from the design. Whether they're mistakes, misinterpretations, or willful mods ("this will work better"), they're still potential bugs, often missed by testing based on the original design.

That being said, it becomes apparent that the problem of hiding such modifications is only unethical when they're willfully hidden. The scale of the violation of ethics is given by the knowledge of the danger of the hidden modification. For example, if I discover a possibly misleading scale difference in a series of user interface screens on a software-controlled aircraft, my boss might not want to do anything about it in order to keep the project from going over budget so s/he can get his/her bonus. That's unethical, because it's a willful decision which conflicts with what one knows ought to be done.

Re:External Pressures Ruin Engineering

[TemporalBeing]

There is a point you miss there I think. It is the top-to-bottom design philosophy vs the bottom-to-top. The first one gives objectives first then designs every part so that it fulfills the general objective. The latter focuses on designing simples elements and assemble them as more complex elements with defined capacities and known weaknesses.

This article states that the second approach is inherently better than the top-to-bottom approach. This is clearly an engineering problem. I am not sure I agree with the conclusions and acknowledge that most of the Challenger disaster was due to unwelcomed pressure, but I don't think you can dismiss the whole issue as not concerning engineering. I wouldn't necessarily agree that the Top-Down approach is 100% bad. Both have their strengths and weaknesses for what they can see and cannot see. Bottom-up tends to get too involved in the details, while Top-Down tends to outright ignore the details.

However, please, please, please,..(can I say it enough?).., please do not mix the two - have one part top-down and another bottom-up. Be consistent in design methodology across the entire project, and find the appropriate balance of both methods.

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

But I do agree that tradeoffs occur under any system. Those tradeoffs just let us make better decisions under capitalism whereas we can't allow the information from those tradeoffs to inform us economically in a socialist system.

Wow, random assertion. I have no idea why this would be true, and a good body of work seems to suggest the opposite.

Capitalism clearly makes poor choices about these tradeoffs when their monitization is incorrect, but so does socialism. Other than that, capitalism seems to make worse decisions by weighing the costs by the likelihood of being held responsible, the ability to settle for less than that amount because of the costs of extracting it (a trial), and a variety of other externalizing factors. Socialism, on the other hand, does not externalize these costs.

Re:External Pressures Ruin Engineering

[Protonk]

the repair was done by military personell and the reason the wrong bolt was used was that controlled material wasn't segregated from uncontrolled material.

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

[AJWM]

The engineering part was originally flawed in that it could not be built as designed. That three story rod wasn't threaded its entire length in the original design, it was just threaded where the bolt attached. Looked good on paper, darn near impossible to fabricate. That said, though, it would probably have worked if the entire length had been threaded (although threading adds its own set of problems).

Re:External Pressures Ruin Engineering

[Anonymous Coward]

I'm a PE so let me comment about the reality of how things work.

1) The majority of Engineers are NOT PE's. The only field of engineering that has around 40+% PEs is Civil Engineering for obvious safety reasons. I really doubt that even 1% of the Electrical Engineers at Intel, IBM, AMD, Apple, GE, etc. have a PE. So the argument about how engineering is this great endeavor and software development is not is bogus.

2) As long as a PE follows the excepted Body of Knowledge for their field they are safe. Currently a software developer can be taken to court, but can't use this for excuse for protection.

3) When things go bad PEs are reviewed by other engineers that also have PEs. These boards are just as likely to pull a fellow PEs license as a state law board is to pull a fellow lawyer's license. I've seen this over and over. You have to REALLY screw up and it has to be very public before anything serious would ever happen to you.

Moving forward there are domains that software developers work in that PEs might be quite useful out of public safety interests.

Re:External Pressures Ruin Engineering

[oldhack]

It's bit of cop-out, no?

Managing cost vs quality/risk has been part of engineering discipline for a long time. Engineering isn't science, and even in science, cost (funding) is a hard taskmaster.

Anyway, it's the same old story. After a few runs without problem, we (bean counter side of the collective "us" - you know what I mean ;-) cut corners until a shit hits the fan again. We overreact to tighten things up being super-conservative, we get a few good run without a hickup, and the cycle continues.

Re:External Pressures Ruin Engineering

[Specter]

To some extent, things this was also a communications problem. Edward Tufte has analyzed the Challenger and Columbia disasters and concluded that they largely occurred because critical information became obfuscated as it moved up the decision tree. Take a look at his analysis of the Columbia disaster:

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB&topic_id=1&topic=Ask+E.T.

Challenger has similar issues. I can't find a direct cite for it but this page:

http://www.asktog.com/books/challengerExerpt.html

does an OK job of excerpting the ideas.

Re:External Pressures Ruin Engineering

[Watson Ladd]

Companies decide what products to introduce based on surveys.

Re:External Pressures Ruin Engineering

[JonathanR]

I've just looked at the Wikipedia article (and sketch) showing thw defect. As an engineer (yes, a real one, albeit mechanical discipline), all I can say about what was done is, what an unimaginative solution.

They could have still split the threaded rod under the upper walkway, and re-joined it with a threaded coupling, just below the nut supporting the upper walkway. If the nut can support the upper walkway, then the threaded coupling could easily support the lower walkway.

In my experience, the solution used just smacks of a "quick fix" coming from some ignorant construction engineer/supervisor. I also would bet that those who approved the change weren't those who conceived the original design.

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.

Re:External Pressures Ruin Engineering

[sjames]

It's much worse actually. The original engineering WAS flawed. The contractor's request was driven by the impracticality of the original design. The contractor didn't believe that the 2 stories of threading would be in usable condition after hoisting the structure into place. Re-threading 2 stories worth of threading in place would be a real problem.

Even worse, even if built as originally designed, it would only have had 60% of the strength called for in the building codes.

The approved design change was really just the final straw (though it was a huge blunder and probably turned a serious problem into a fatal one)

Re:External Pressures Ruin Engineering

[CodeBuster]

What does capitalism and competitiveness drive us to do? Cut corners, often. Perhaps, but there are two sides to that coin. It is only through new problems or challenges and the competition to solve or overcome them that we move forward as a species. If there is no competition, no risk taking, and no ambition then we are just as likely to become overly cautious naval gazers, afraid undertake even the most trivial of tasks or miniscule riks in the name of progress. I agree with the ideas in Feynman's paper and Gustavo's blog, but the problem is not capitalism or competitiveness per se but rather foolishness on the part of the uninformed, whether they be NASA managers, corporate executives, or software engineers, and that can happen under any system. So why discount competitiveness entirely when a balanced approach has higher expected value? We can have more of both innovation and quality, provided that we are wise enough to navigate the optimal course.

Re:External Pressures Ruin Engineering

[AJWM]

Well, as I said, threading adds its own problems.

You raise a valid point about several factors coming together. I am (or rather, have been) both a pilot and a scuba diver, and I've attended safety seminars in both fields. One thing fairly constant in fatal accidents -- more than one thing went wrong, and if the pilot/diver had called a halt at the first -- or even the second -- thing, they'd still be alive. The thing is, we all tend to build up a body of experience that tells us that "just one thing" being wrong won't hurt. Like one of my boys, when I advise him against the risky behaviour he's engaging in, "well, I haven't fallen/broken it/whatever yet".

With both Challenger and Columbia there was evidence that they'd seen similar problems (O-ring blowby and ice damage to tiles) though on a lesser scale on earlier flights. One wonders how much that built up a degree of complacency rather than concern. "It hasn't been a problem yet."

Re:External Pressures Ruin Engineering

[Anonymous Coward]

Feynman's piece basically arrives at the same conclusion you do.

His main criticism is not of the engineering involved that led to the disaster, but of the perception and representation of the safety on the part of management. He contended that management deluded themselves into believing that the probability of failure was 1 in 100,000 rather than the roughly 1 in 100 that Feynman contends. He mentions specifically that professional astronauts come from a test pilot background, know the risks involved in this type of flight and knowingly take those risks (and that their bravery should be noted). But that management exposed a civilian to those risks while presenting a delusional picture of the risks involved was the biggest problem.

In essence, what he's describing there is exactly what you're talking about. That anything engineered will fail some percent of the time. It's that percentage value that should be the result of the cost/benefit analysis and it should be realistic. He also mentioned that internal NASA reports from engineers came much closer to approximating the actual failure rate and it was management in particular that was misrepresenting the situation.

He did go into some of the mistakes (fitting the accumulated erosion of the rubber seals to a curve rather than discovering why the curve was the way it was) and successes (the software engineering), but that too was an indictment of management since he cited a recommendation on the part of management that the testing budget for the software should be cut back rather than realizing that the that sort of testing was what was needed for the physical components as well.

His one admission that management might not have been entirely at fault was the mention that their actions may have been partially driven by funding concerns, which would seem pretty reasonable. If Congress punishes NASA for truthfully telling them when something is wrong, then they shouldn't be surprised when NASA tells them everything is fine when it actually isn't.

Re:External Pressures Ruin Engineering

[turbidostato]

"Edward Tufte has analyzed the Challenger and Columbia disasters and concluded that they largely occurred because critical information became obfuscated as it moved up the decision tree."

Every time you need to reduce a 300 pages technical review into ten powerpoint slides in order to "move it up the decision tree" you know some critical information will become obfuscated on the way.

Re:External Pressures Ruin Engineering

[Protonk]

It isn't the what that is the particular problem in ordering society. It is how much and for who. those are the important questions. The what is (if you'll take a small leap of logic) a subset of those two questions.

Companies decide how much to produce based on their costs. They decide WHO to give it to based on who can pay for it. An awful lot of efficient allocation occurs without the need for a survey. What we really mean when we say "survey" is this:

Would you like a car?
Yes/No

How much would you say a car is worth to you?
X,000's of dollars

Is there a special reason you need a car?
Grandma is sick, etc.


What is to stop people from lying? Do you create a HUGE govertment sector to enforce compliance? Isn't there an easier way? Hmmmmm.

Re:External Pressures Ruin Engineering

[Meski]

Do you stamp/sign every line of code you let go? Are you personally liable for anything you approve with your sign/stamp? If not, don't use the term professional engineer. If a "software engineer" screws up and is fire, they go somewhere else to work. If an engineer scews up and is fired, they most likely won't be able to find somewhere else to work in their field. I think you could say that committing code into a VCS *is* the effective 'signing' of every line of code you let go. So yes, professional engineer. If you screw up (in what you've committed) it depends on the seriousness of the screwup. Does it corrupt every customer's data? Time for a change of profession, most likely. A fair degree of blame would go to the testers also.

Re:External Pressures Ruin Engineering

[Detritus]

Being a cynic, I would argue that the Big Dig has met its primary objective, filling the pockets of the politically well-connected with large amounts of other people's money.

Re:External Pressures Ruin Engineering

[Yvanhoe]

Bottom-up tends to get too involved in the details, while Top-Down tends to outright ignore the details. The thing is that two accidents have already proved that you can never get too involved in the details. Or that it didn't happen in the Shuttle project.

Anyway, int the GP I was just posting some observations about TFA, I am not sure I agree with all their conclusion either.

Re:External Pressures Ruin Engineering

[roman_mir]

What does capitalism and competitiveness drive us to do? Cut corners, often. - but have you never heard of communist regimes fucking up badly due to corner cutting? Chernobyl?

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

First off, Socialism != Communism. In socialism, goods are allocated based on a person's desire to pay. The main difference in socialism vs. capitalism is government vs. private ownership of the companies. That is to say, whether there are government light bulb factories (for instance.) This fact implies several others, but it is irrelevent.

My contention, which you seem unable to refute as you shift off into capitalism is better than communism base triteness, is that capitalism allows costs to be reflected at less than full value. This is because there is an inherit likelihood that liability will not be proven. Also, even if liability could be proven, they may be able to stretch out when to pay (money in the future is worth less) or use the threat of that to settle for less than the actual cost. In socialist systems, those same externalizing factors do not apply.

Re:External Pressures Ruin Engineering

[rprins]

IMHO, the best approach is to design something bottum up.
Then throw that away and design it again top-down.

However with software engineering the designing and developing the solution is very rarely a problem. The problems we always see are created by extra functionality or different functionality that was added in hindsight. Thus, the most important part of the design process thoroughly determining the functional requirements and then carve it in stone. Which is something you don't do when designign bottum-up, btw.

Re:External Pressures Ruin Engineering

[Protonk]

Of course socialism doesn't equal communism. Take all of my arguements and replace the word communism with the word socialism if it makes you feel better.

Ok.

with regard to consumption and the allocation of goods:

Capitalism allocates goods according to ability and willingness to pay. Socialism allocates goods according to needs (or wants, edepnding on the semantics).

That's the fundamental allocative difference. My argument is that allocation based on desire cannot be done effectively unless you have a means to compel truth telling or a complete breakdown of desires among people. There is no way to prove that I need a car more than you without intrusive surveillance.

This may result in prices (in a capitalist society) that diverge from the sum of the inputs. this fact should be self-evident, but the conclusions to be drawn from it are not assured. Just because the price one company will charge for a good does not reflect the cost of the iinputs does not mean that funds are misallocated. For one, if the company charges TOO much, another company will form and eat up the unexploited profit. You can't keep charging 1000 dollars for a telephone, someone will realize that it only costs 500 and figure there is a market to be made selling them for 750. The more companies there are, the closer the price will converge on the sum of the inputs (the marginal cost). Sometimes the price does not converge on the marginal cost. This isn't necessarily a bad thing.

are you suggesting somehow that the very nature of capitalism makes it so that costs will not be accessed by the producers for their "full value"? who makes that valuation? Who is responsible for saying what the value of a dozen roses is? If we are talking about the value of human lives, we have to accept one of three possibilities:

1. Human lives have no value.

2. human lives have an infinite value.

3. Human lives have a value that lies between zero and infinite.

A government and a business would both come to the conclusion that 3 is the best choice. the corporation would come to the conclusion that a human life is worth some function of their future earnings and plan accordingly. the government would make the same conclusion. the fact that liability is not assured doesn't figure in.

How are things different in a socialist society? Where is the magical source of valuation that socialists can draw from which is more accurate than capitalists?

Re:External Pressures Ruin Engineering

[Stooshie]

... most of which weren't obviously predictable without hindsight ...

Ahem, isn't an engineer's job to reduce the need for hindsight? And cutting corners from an engineering perspective, increases the risk of "if only we'd ...".

The parent was right about risk versus consequences.

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

Capitalism allocates goods according to ability and willingness to pay. Socialism allocates goods according to needs (or wants, edepnding on the semantics).

The concept that socialism involves the government spying on you, and allocating goods on your behalf is a strawman (and a diversion). Socialist societies and capitalistic societies tend to allocate goods in the same manner, by offering them for sale at a fixed price. The difference is the ownership of the means of production. And in both systems, surveys, etc. are used to plan product lines.

You may have been misled by universal healthcare being labelled socialized medicine. In reality, while closer to socialism than capitalism, it is in fact neither.

are you suggesting somehow that the very nature of capitalism makes it so that costs will not be accessed by the producers for their "full value"? who makes that valuation?

Sure, human lives have a finite value, in America I believe the high six-digits is the average value. My point is that regardless of who makes that valuation, the system prevents the full costs from being passed on to the producers in a capitalist system. Because of the externalization present in the system, whatever price the producers end up paying is less than the actual cost, because society assumes a non-negligable percentage of the cost. Since, in socialism, there is no difference between the producer and society, the full cost is recognized by the same party. Hence the efficency.

The right mix of socialism and capitalism in a society is up for debate, including 100% one way or the other. But it hardly propels the conversation forward to ignore the inherit virutes of either. One of socialisms virtues is that it solves the externalization issues that are present in capitalism, and thus is more sensitive to the real costs associated with shoddy engineering.

Re:External Pressures Ruin Engineering

[Protonk]

I don't know where the assertion that I somehow am confused about health care came from. health care is one of the sectors in economies that benefits from government intervention (if not neessarily government ownership). There are cases to be made that numerous market failures cause the private sector to result in an inefficient outcome. The case is pretty clear, if you are anyone but an insurance company, that health care could stand with more regulation rather than less.

But we aren't talking about health care. We are talking about the allocation of goods. I'm not talking about production. I said that like two posts ago. My point about information has to do directly with the allocative problem. We can talk about the production problem as a function of the allocative problem, but that just obscures things. It is like talking about who pays sales tax. It is nonsensical to speak of sales tax as being paid by the customer independent of choices made by the producer. Whoever the sales tax is imposed upon, it changes decisions for the other.

My point is that the pricing system allows a capitalist society to use information particular to individuals and times without centrally ordering things. Sure, a capitalist system usually has a market price for something, but that is always negotiable. Bannanas are 99c/lb at the store. You can feel free to pay the store more for the bannanas if you like, they will probably accept it. You might also be ably to pay less, if you can negotiate a new price. That market price simply saves you the cost of negotiating. Most people negotiate for big ticket items (cars, houses, etc) but accept market prices from smaller items (bananas). Part of this has to do with volume for the seller (a supermarket probably doesn't give a shit if you want to spend 97c for bananas instead of 99 and won't bother to negotiate with you) but it also has to do with worth to you. It is worth your time to negotiate that extra 1000 dollars for the car but not worth it to negotiate that 2 c for the banana. So those market prices and your willingness to buy things AT the market price are the result of a mutually beneficial transaction. You pay 99c for bananas and you have signalled to the market that bananas are worth at least 99c to you.

Those signals exist at the allocative side but they aren't limited to there. I don't want to say start and stop because it is kind of like saying where electric current starts and stops. That decision for bananas provides signals to distributors and producers of bananas. They base their production of bananas on how many they can sell at a price profitable to them. If they can't sell enough at a certain price, they produce less or charge less. Those signals come directly from the fleibility of producers and consumers to come to agreement on prices. If they can't come to an agreement (say, there are price controls in place), then less information gets across. Even more than that, some information gets across (customers would liek to buy more gas than is currently supplied) but can't be acted upon (price controls make it unprofitable for the companies to sell gas at a higher price in order to ration it). The price-information system at the buter level DIRECTLY impacts production decisions.

I'll ignore the canard about business using surveys in capitalist societies.

You last point might have some merit. There are externalities in production (and consumption). They don't relate to the discussion as liablity laws mean that safety costs get internalized by the firms. You might argue that they don't fully internalize them but I think it is a distinction of degree. I don't think it is a forgone conclusion that socialism provides a means to recognize and internalize those externalities. Some may not be fully known. In the 1920's when we put lead in gasoline, we had a pretty good idea it was bad for you. The government knew. Charles Keating and Al Sloan knew. We did it anyway (what might be considered a classic negative externa

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

Your entire view of socialism is a strawman, because socialism has many implementations and you attack only one. Socialism also includes many competing companies in each field, so long as the ownership of those stocks is in government hands. It includes councils voting on what to produce and what level to set the prices. Just as "democracy" means different things in the US, Russia, France and the UK, socialism has similar differences.

Some versions of socialism avoid the issues you bring up, and hence, it is a strawman.

The last point you make seems to miss the source of my critique. I do not claim that socialism is better at determining the cost of negative side effect X. In fact, in my first post, I say that in the case that is unknown, both capitalism and socialism have huge issues. My point is, suppose a magic fairy told you the cost of X was Y. In a capitalistic society, because some of the cost is externalizable (see parent analysis), the cost paid is some Z, Z < Y. The difference between Z and Y (call it E) is borne by society. In capitalism, the companies owners only need assume cost Z plus the same percentage of cost E as their proportion of society. In socialism, since society is the owner, they assume the full cost of E (they are 100% of society). Hence, in socialism, the total cost is Z + E, or Y.

Re:External Pressures Ruin Engineering

[Protonk]

I can't begin. I think that I have articulated a pretty solid argument against the general notion of socialism as a means to allocate goods. To call it a straw man is silly. You may tell me that you don't think that pricing/allocation is all that important and then explain why. You may tell me that consumption is unimportant and explain why production dominates. But you can hardly tell me that it is a straw man and ignore the rest of the argument.

Ok. Let's assume that multiple government organizations do own corporations. Presumably, competition between the two would only be allowed insofar as the government saw fit, because if we were to have true competition, the same motives that exist running a capitalist business would be in place here. And in this case it is demonstrably worse to have government running these companies. Government is the only agent here that can compel action. It holds a monopoly on force over individuals. To say that government would allow organizations to run in ways that hurt others (say, via competitive action) is silly.

Even if we assume allocative issues don't exist, there is still the issue of ownership. Why does government exist as some privileged owner? Why is wealth concentrated there? How is it evil for profits to be concentrated in the hands of owners of capital but just for them to be concentrated in the hands of the government? More to the point, how does government ownership effectively simulate the profit motive?

And it isn't a straw man. Just like I tried to explain about the sales tax paradox, we can't talk about who controls one sector of the economy without talking about how it impacts all the rest of the chain. If I set government imposed limits on the production of cheese, that will impact the end consumer for cheese. If I set price controls for cheese, that will impact producers. If government goals dictate production then they impact allocation and consumption, period.

Right. I understand your last point. I'm not missing it. Some things have external costs. Private companies only see private costs and so produce more than should be produced, given that external (social) cost. In a socialist society, that external cost is borne by society (lets say it is more lung cancer from pollution) and paid for by the same companies. Whoop-de-fucking-do. People still get lung cancer. We just all pay the same bill.

Dealing with that externality can be done in a capitalist OR a socialist society. Simple control over the means of production by the government does not somehow imply that the government will produce less in order to bring the externality into account. you produce some symbols here but at no point do you give any logic as to how the external cost will change allocation/output. that is the important part. Society already bears the cost, capitalism or socialism. How it deals with the cost is not a function of what kind of government it is. Take a look at the Clean Air Act in the US. This was a market solution to a social externality problem. Pollutors put out too many pollutants. The government created a cap on those pollutants and allowed companies to buy and sell permits to violate that cap. Companies were forced to internalize those social costs and pollute less now. Capitalist solution. Capitalist society.

We can also have price control and government ownership in capitalist societies. The prices of milk and corn are both highly regulated in a truly arcane fashion in the united states. imports of cane sugar are limited in order to keep prices artificially high.

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

. I think that I have articulated a pretty solid argument against the general notion of socialism as a means to allocate goods.

You have articulated an argument against government dictating allocation. However, that is only one varient of socialism. Market socialisms, which uses market prices to inform production decisions, also exist. That is why it is a strawman.

How is it evil for profits to be concentrated in the hands of owners of capital but just for them to be concentrated in the hands of the government?

Because the government inherits the responsibility of cleaning it up. They both get the profits and the costs of pollution. Your example of the Clean Air Act was a good example of the government taking corrective action to move those costs back where they belong. However, all such action will be imperfect. In a socialist society, the alignment is automatic and perfect, as opposed to constantly in flux.

Re:External Pressures Ruin Engineering

[Grishnakh]

Risk is OK if the dangers aren't really preventable, like failures in engineering due to lack of knowledge (insufficiently advanced technology and science). It's not OK when the dangers are caused by greed or other human problems.

You mention going to the moon. The US sent many manned missions to the moon, and not a single one failed with fatalities. Only one failed, and disaster was averted thanks to great engineers who came up with workarounds. To me, that's pretty amazing considering no one had ever sent men to the moon before. Yes, there was the one crew that was lost on the launchpad during a training exercise IIRC, but that wasn't even a moon mission.

If I were an astronaut, I'd be happy to risk my life for the advancement of mankind with a team like that behind me, where the engineers and managers and government were really doing things properly, to the best of their ability, not cutting corners to save money, not risking safety in any way. America did that in the late 60s, and got men on the moon in a remarkably short time considering airplanes had only been invented less than 60 years earlier. However, I would NOT be willing to risk my life with a team/nation behind me where engineers are overruled by incompetent and shortsighted managers due to political pressures and the like. If you're too lazy or cheap to do a dangerous and important project the best way you can, then don't expect me to help you out. The way things are being run in the US now, there's no way in hell I'd sign up to be an astronaut. I have no trust in the people at NASA and associated contractors to do everything right, and not make another screwup like Challenger and Columbia.

Re:External Pressures Ruin Engineering

[Grishnakh]

I think you could say that committing code into a VCS *is* the effective 'signing' of every line of code you let go. So yes, professional engineer. If you screw up (in what you've committed) it depends on the seriousness of the screwup. Does it corrupt every customer's data? Time for a change of profession, most likely. A fair degree of blame would go to the testers also.

Tester? What's that?

I work as a software engineer. We don't have any "testers", except for the customers. If the customer finds problems, we fix them, and let them test the next revision.

Not every workplace or project has the resources to have separate engineers, testers, etc. In most software jobs I've seen, even involving embedded software (which I currently work on), the product is basically hacked together by a very small team, with no testing whatsoever except by the engineers themselves. Of course, none of these projects were life-critical in any way, which probably explains why these companies weren't terribly interested in paying huge amounts of money for more rigorous software development procedures.

Re:External Pressures Ruin Engineering

[Protonk]

I'm done. If you still say something like this:

However, all such action will be imperfect. In a socialist society, the alignment is automatic and perfect, as opposed to constantly in flux.

After the back and forth we have had there is no convincing you. But for the sake of curiosity, tell me how the alignment is somehow perfect in a socialist system and yet flawed in a capitalist system. Tell me what superior font of knowledge informs socialist systems that eludes capitalists (who believe me, would rather have unperturbed growth over the volatility of the business cycle). Tell me how the government can generate the same efficiency outcome as a system driven by the profit motive when not motivated by profit. I'm not ignorant. I understand that governments can manage things well and sometimes have incentives to manage things much better than corporations: public goods, externalities, and other market failures are examples of where government action is preferred. But there is a strong case for areas with no significant market failures to be mediated by the market. How does socialism generate the same optimization as millions of actors seeking out maximum private profit at once?

If you are going to tell me some nonsense about "automatic alignment" without any supporting arguments, don't.

Re:External Pressures Ruin Engineering

[Grishnakh]

I would say that in general is the meta-problem, not capitalism. In its current form in the US capitalism has caused the existence of many large entities that use hierarchical systems of command and control. These hierarchical systems frequently make sub-optimal decisions because individual actors within the system act for their own benefit but against the benefit of the larger system they are a part of. Particularly egregious examples of this can be found, and they tend to be highlighted as aberrations, but they aren't. They are merely extrema of a problem that is widespread.

Bureaucracy in general serves to insulate actors from responsibility for the results of their actions. As I recall we didn't see any of the middle management of NASA held accountable for the disaster they caused by attempting to look good for their superiors and the public. And this failure of accountability is endemic to the kinds of hierarchical systems you see in most bureaucracies.

What I don't understand is WHY there's no such accountability in cases like this. I don't see why it's not possible to have a hierarchal system of command and control, even a bureaucracy, but include proper accountability so that individual actors who act against the benefit of the larger system are punished, and those who act for the benefit of the larger system are rewarded.

Re:External Pressures Ruin Engineering

[Grishnakh]

And most importantly, we should stop offering people the option to build bug-ridden pieces of crap. That is frequently what people want in the short term, but never what they want in the long term. It's unprofessional, it harms relationships, and wrecks the image of our profession. That's not to say we should insist on gold-plating everything, pursuing technical perfection that has dubious real-world merits. But in the same way a licensed engineer would not see building a shoddy bridge as an option, we should stop treating buggy, low-quality software as the norm.

I disagree. The customers WANT shoddy, buggy software, because it costs less. If you don't offer it to them as an option, they'll find someone who will.

The only reason you don't see licensed engineers offering shoddy bridges as an option is because 1) there are government standards for bridges and structures which prevent that, 2) these engineers are accountable for problems with their bridges due to the laws in place, and 3) the customer for all these bridges is the government (state, local, etc), not a for-profit company or individual. For buildings, it's much the same, although many of the customers aren't government-related: there are strict standards in place, enforced by the government and the legal system, to prevent most cases of shoddiness, even when customers are cheap. If there weren't government standards in place, we WOULD see lots of collapsing bridges and buildings. In many 3rd-world countries, it's not that unusual.

With software, there's no such standards enforced by government, so there's certainly no incentive on the part of engineers or their employers. Any company that tried to force its customers to pay extra for quality (and wait much longer between releases) would be driven out of business by competitors. For non-life-critical things, customers simply don't demand quality. They may pay lip service to it, but they won't pay for it.

Re:External Pressures Ruin Engineering

[Omnifarious]

Bureaucracy has a strong tendency to diffuse accountability. There is a marvelous fictional anecdote about how this happens:
The Hierarchy of Power Semantics.

Who in the chain in the anecdote is responsible for the bad decision? And that pretty much mirrors exactly what happened in the shuttle disaster. The engineers at the bottom knew there was a serious problem with flying in cold weather because of the O-rings, but at every step of the chain the problems reported at the lower level were made a little and happier for the level above.

Re:External Pressures Ruin Engineering

[Actually, I do RTFA]

But for the sake of curiosity, tell me how the alignment is somehow perfect in a socialist system and yet flawed in a capitalist system.

In a capitalist system, the government has to absorb the cost of the externalities. It then has to figure out some method of charging those costs to the people who generate them. This method is never going to be perfect, and will likely oscilate between charging too little and too much. In a socialist system, the externalities are still absorbed by the government, but the government also generates the externalities. So there is no need to invent a system to try to push the full cost for the externalities onto their generators.

This point was actually all I was trying to say. I tend to be more capitalist with progressive taxation and a strong floor than socialist. The major exception I have comes from planned obselecence and externality production. So, I really do enjoy trying to figure out how those can be brought into a more capitalisitic society. The whole optimization arguemnt seemed like a sidetrack to me.

Tell me what superior font of knowledge informs socialist systems that eludes capitalists

None

Tell me how the government can generate the same efficiency outcome as a system driven by the profit motive when not motivated by profit...How does socialism generate the same optimization as millions of actors seeking out maximum private profit at once?

This part of your argument irks me because "millions of actors" using market forces is not antithetical or even incompatible with socialism. It is incompatible with some versions of socialism. But not Market Socialism. The defining characteristic of socialism is that government owns the capital.

Frankly, as you start delving further and further into any economic theory, they all look the same in their extremes. A totalitarian communist government and the debt-slavery under a monopoly where debtors are denied the vote, freedom of travel, etc. are fairly equivalent. It's like those examples of mathematical games where combining two losing strategies randomly leads to a winning one.

Re:External Pressures Ruin Engineering

[dubl-u]

I disagree. The customers WANT shoddy, buggy software, because it costs less.

But it doesn't. Crappy software costs a little less in the short term, and much more in the long term.

If you don't offer it to them as an option, they'll find someone who will.

Some will. Some won't. The smart ones eventually learn.

Take a look at Google, for example. They make rock-solid stuff, they are very focused on cost efficiency, and they devote so much effort to testing that the have an internal testing conference and a guerilla campaign to promote testing. They know that quality pays off heavily in the long run.

They may pay lip service to it, but they won't pay for it.

I think we have done a terrible job of selling it. These days, I just tell the clients I'll use "best practices", and I don't even offer them the option of doing dumb stuff. Instead, when they want to make things come out faster, I show them how to be radical about cutting scope. Train them properly in that, and they'll forget about the (false) choice of adding bugs.

Re:External Pressures Ruin Engineering

[drinkypoo]

You're just being overly pedantic and ruining a good thing. We can call it bottom-up because it is a fundamentally different style of programming. I mean, you could argue that you literally can't write bottom-up unless you start not by writing a single function (Except in languages which require it) but by referencing a single function. Strictly speaking you are not starting at the absolute bottom unless you begin with one functional line of code. Problem with that is that it's basically impossible to define, much less do. You can't get anything done with just one line of assembler, and do we define one line in the high level language, or at the instruction level?

It's simplest to just accept that top-down means that you plan before you start and bottom-up means that you begin at the basic functional level and work your way up. Almost everyone actually works from both ends, but the difference is in how you begin. Once you reach the maintenance phase all bets are off, but I think we're just talking about initial development here anyway.

wow

[loconet]

For a second there I thought I read "Rogers Communications" and "brilliant" and "engineering" in the same sentence. I thought I had been kicked to an alternate universe where I wouldn't be able to escape. I am glad to be back.

Slashdotted

[EricWright]

Did anyone get through before the story hit the front page? I'd be interested in reading, but Google doesn't have a cached version of the story.

Re:Slashdotted

[techno-vampire]

You can get through now. However, at the top is a note that the site had been slashdotted and moved to a new box.

A future essay...

[StarfishOne]

A future essay relates Feynman's commentary to modern web hosting, load balancing and the so-called Slashdot effect"

Mirror

[fishdan]

http://duartes.org.nyud.net/gustavo/blog/post/2008/02/20/Richard-Feynman-Challenger-Disaster-Software-Engineering.aspx As a side note, could someone make a grease monkey script to make all links frmo /. run through coral? it just makes sense

Re:Mirror

[Chris Mattern]

Slashdotted as well.

Re:Mirror

[s_mencer]

There is already a script that does that:

http://userscripts.org/scripts/show/1851

Yeah, BUT...

[StCredZero]

I scanned TFA and I'm not sure he has a clue about Linux, IMHO. He appears in the 5th panel of this very cool webcomic and you don't!

Re:Yeah, BUT...

[drharris]

Does anyone find this comic entertaining or amusing? Perhaps my geek cred is lacking, but when I tried to appreciate it I felt like the only sober guy in a room full of acid trippers.. I just don't get it.

Re:Yeah, BUT...

[RxScram]

Nope, I don't find it either entertaining or amusing, either.

Re:Yeah, BUT...

[s_p_oneil]

No, you're right. That one sucks. The best comics for programmers would probably be xkcd (on the serious side) and Narbonic (on the silly side).

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.

Re:Yeah, BUT...

[AJWM]

It's hysterical. I'd never seen it before, but now I have a new time sink (oh, joy) as I wade through the archives. Lots of bad puns (Dresden Codak? right) in-jokes, and great artwork (love the Paul (Muadib) Atreides and Morloks in the very first cartoon).

Yeah, maybe you need to turn in your geek cred. Or get your head out of a programming manual and into something else once in a while.

Re:Yeah, BUT...

[s_p_oneil]

Hmm, maybe it appeals more to people in certain areas. I still think Narbonic (starts here: http://www.webcomicsnation.com/shaenongarrity/narbonic/series.php?view=archive&chapter=9763) is the perfect comic for any "true geek" programmer. The artist is a woman and not a programmer, so I have no idea how she got Dave's lines so perfect. She must've had a really close friend or significant other to get a lot of that material from.

Re:Yeah, BUT...

[WilliamSChips]

For some reason, the person linked to one in the middle of a storyline. Have you started at the beginning?

Re:Yeah, BUT...

[drharris]

For some reason, the person linked to one in the middle of a storyline. Have you started at the beginning?

No, and I think that's what caused the confusion. I looked back in the archives and things make more sense now.

slashdotted

[esocid]

already?

Faster, Better, Cheaper

[Protonk]

To be fair, the Challenger disaster actually preceeded NASA's slogan and procurement policy of "faster, better, cheaper" by a bit. More to the point, Feynman's article should be a cautionary tale to ANYONE in a engineering field. It isn't a matter of one field being subject to unscientific pressures and another field being immune. No technology or industry is immune from the pressures and problems that caused the challenger disaster. Anyone who claims to be well adapted to safety concerns enough to not spend lots of time and effort on fixing them is foolish. The nuclear industry still has to practice strong QC on parts, procedures and maintenance and CONTINUE that practice. Same with commercial aviation, acute medical care, etc. Constant vigilance is rewarded only with another uneventful day. That is the fundamental problem. Vigilance is expensive and time consuming. these are not pressures from the profit motive. They apply to government as well as civilian ventures.

Re:Faster, Better, Cheaper

[Anonymous Coward]

In Feynman's report on the Challenger, while detailing problem with the o-rings, he also pointed out the reason for a two part booster design, when a safer one piece booster could have been built.
It seems a safer one piece booster would have needed to be built locally, but the spec was opened up to allow a 2 piece booster design, in the goodness of completive bidding. The problem with the one piece design, was that the booster couldn't be shipped from Utah ...

Re:Faster, Better, Cheaper

[Protonk]

Right, but these tradeoffs exist everywhere. If the engineering team had been allowed to do their work appropriately they would have accessed the 2 pc o ring and rejected it based on safety concerns. The fact that it came from a lower bidder isn't really prima facia evidence that capitalism caused the challenger accident. :)

Re:Faster, Better, Cheaper

[DaPhilistine]

Meerkats seem to have the vigilance to effort ratio about right in a demanding environment, maybe we should take some lessons from their societies and apply them the engineering world:

From wikipedia:

The alpha pair often scent-mark subordinates of the group to express their authority, and this is usually followed by the subordinates grooming the alphas and licking their faces.

Re:Faster, Better, Cheaper

[avandesande]

Yes, like it or not cost analysis and time to market are integral to engineering. Finding the correct balance is what make a great engineer.

Re:Faster, Better, Cheaper

[steelfood]

Constant vigilance is rewarded only with another uneventful day. That is the fundamental problem. Vigilance is expensive and time consuming.

You're absolutely right. In this society dominated by the results/delivery-driven mentality, things that do not directly contribute tend to be marginalized. See how companies offshore support and QA because these divisions do not actively generate revenue. It is the same thing.

For something like QA, no news is good news. For management, no news is waste. Management's mentality is, "We don't pay you to sit around and do nothing." And so they cut QA time and resources.

Re:Faster, Better, Cheaper

[oldhack]

...Constant vigilance is rewarded only with another uneventful day. That is the fundamental problem. Vigilance is expensive and time consuming...

What the quote says. Worth repeating, I thought. Maybe those of you in evolutionary biology can add something insightful why we have this problem, and more usefully, how to address the problem.

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: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.

Re:Tag on to a famous essay...

[Actually, I do RTFA]

Richard Feynman is one of the greatest safe crackers who ever lived

You're only saying that because he cracked the safe with every bit of information the US had on how to make an A-bomb after the Trinity tests. On second thought, I suppose that is pretty good.

Re:Tag on to a famous essay...

[Fysiks Wurks]

Why are you flaming the author? Yes I RTFA. Taking an essay by a brilliant and insightful person then writing down how those insights translate to your specific situation is a self educational process and can lengthen the retention of the lessons learned (Hmm..sound familiar...some classic petegogy here). It is a personal blog and the author is summarizing the lessons he takes away from the Feynman report, the author is not trying to garner coattail genius status.

Various degrees of learning and retention can be achieved through both writen and verbal communication.

Re:Tag on to a famous essay...

[KnowledgeKeeper]

What we need is a Richard Feynman Day. The date could be something witty, like 12.3. (12th of March) which could mark his I.Q. :)

Re:Tag on to a famous essay...

[Zarf]

What we need is a Richard Feynman Day. The date could be something witty, like 12.3. (12th of March) which could mark his I.Q. :) I say we start it as a world wide grass roots movement... ala talk like a pirate day ...it'll start out with a web-page claiming more participants than actually observe and then grow from there to mythical proportions. First tradition on Feynman Day is to tell someone about Feynman Day. Okay. Go!

WWRFD

[Anonymous Coward]

What would Richard Feynman do?

Hm.

[gardyloo]

The blog post makes a nice contribution by linking to Feynman's original thoughts (for example, here: http://www.ranum.com/security/computer_security/editorials/dumb/feynman.html ), ones I haven't read for a long time (and was happy to be reminded of). However, the author makes the mistake of thinking that the original thoughts need to be interpreted and summarized for the reader. Feynman's words by themselves are simple to understand, are concise, and contain just the tone for which geeks go gaga. Anyone interested in the subject will be able to make his or her own judgements about the engineering and politics involved in the Shuttle development, engineering in general, and the extensions to software development.

Re:Hm.

[Protonk]

This is a very good point. Feynman has the unique quality of startling intelligence, curiosity, and straightforwardness. Some authors need to be summarized. Feynman just needs to be trotted out every generation or so.

Re:Hm.

[gustavoduarte]

I agree, and tried not to summarize at all. Mostly I just tried to link what Feynman said to software, rather than make a fool of myself paraphrasing him. That's also why the entry is really short, and basically tells people to go read the source :) cheers.

Re:Hm.

[Protonk]

Oh absolutely. I can't read the article right now. :) But I'm not going to crucify you for making the parallels. I remember reading the chapters about NASA's flight software testing and getting goosebumps. It's THAT good. I think you are right for making that parallel and suggesting its relevance. There are a fair number of coders alive today who weren't adults when Mr. Feynman was alive, sadly.

Re:Hm.

[gustavoduarte]

I'm 26, so I'm in that category myself ;)

Re:Hm.

[Protonk]

I am too, except I'm in nuclear power, not software engineering.

Re:Hm.

[gustavoduarte]

Hey, server is back up, you can read it now :) cheers

Re:Hm.

[Anonymous Coward]

Not only that but Feynman talks specifically about software in the Avionics section.

scooped!

[troybob]

And here I was on the verge of releasing my twin papers on how the 9/11 Commission Report can be applied to software development, and how the Warren Commission Report on the Kennedy assassination applies to P2P.

Re:scooped!

[Profane MuthaFucka]

Let me summarize:

9/11 commission report as applied to software development: Your project failed because of perfectly understandable reasons - bad engineering, lazy programmers, poor management, or maybe the problem you tried to solve was just dang hard. Nevertheless, management is going to fire a bunch of people to throw a scare into the rest of the programmers. Then they're going to start a Department of Homeland Programming to make sure that no project ever fails again. For the children.

Warren commission report as applied to software development: a bunch of you can get together to kill your project manager. When the police start asking questions, all you need to do is blame it on the weird programmer who does all the work and they will believe you.

Surely You're Joking

[Yoweigh116]

Offtopic, but I highly recommend Surely You're Joking, Mr. Feynman, 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:Surely You're Joking

[Protonk]

It isn't really off-topic. I think the essay in question comes from the other volume (What do you care what other people think?). Both are outstanding books and well worth the shelf space.

Re:Surely You're Joking

[Yoweigh116]

Oh, man. I had no idea there was a second volume. Purchased. Thank you very much.

Re:Surely You're Joking

[Breakfast Pants]

Narrated on his deathbed? I heard it was narrated through several drumming sessions, and he went on to do several other books after it.

Re:Surely You're Joking

[lachlan76]

From the preface:

THE STORIES in this book were collected intermittently and informally during seven years of very enjoyable drumming with Richard Feynman.

Bottom up easier in software

[esocid]

I'm not sure if he is stating that a bottom up testing method is readily available in all situations, but it sure is a hell of a lot easier with data rather than with physical designs. Scanning and testing code is much easier than building a CPU and testing it from the bottom up (not that I ever have). He does make the distinction that it is less costly in the long run, and I'd probably agree with him, not from experience with this particular application, but experience in general with preventative maintenance. I would rather design something that is tested to withstand its rigors rather than cut corners because it is cheaper now, but potentially more costly in the long run in terms of upkeep and repairs. But what do I know, I'm no computer scientist/software engineer.

Re:Bottom up easier in software

[Protonk]

For critical applications, bottom up design is not impractical. It is impractical for non-critical applications. Even with physical applications, bottom up design has some clear advantages.

I do not personally feel that one of those advantages is overall cost savings. I think that most top-down design programs are cheaper overall than their bottom-up counterparts (all things being equal). However the benefit in terms of clear and understandable safety margins is almost impossible to replicate.

Easy examples I can think of that are physical:

Chemical engineering (starting from carefully chosen components and building up to a complete refinery system.

Nuclear power (Careful material selection, individual design for piping and control systems)

You gotta have some pressure.

[Anonymous Coward]

Otherwise you end up with people who don't develop anything, in general. Yes you have your exceptions, but exceptions won't get the entire job done. Think of it in terms of a water pipe. Make the pipe wide enough, all you get is a trickle. But slowly start reducing the diameter, all of a sudden this pressure is enough to launch the water many feet away.

Argg gg ... your blind!

[Bill, Shooter of Bul]

In order to have a real sense of the "nature" of engineering, you have to look at more than the failures. You have to look at the successes that occurred in the midst of these same pressures. I'd start by looking into the Manhattan project, of which Feynman played a part in. The exercise of finding other examples is left for the reader.

Brilliant analysis of brilliant analysis

[dazedNconfuzed]

While most commentaries on brilliant analysis are not brilliant, a few are.

Edward Tufte's analysis of Dr. Feynman's brilliant analysis is brilliant, warranting a full chapter in Visual Explanations. What makes it special is that it is not "hey, yeah, that's a good idea, I'm smart too" but instead a study of why Dr. Feynman's analysis is brilliant.

Re:Brilliant analysis of brilliant analysis

[Phat_Tony]

I don't have my copy of Visual Explanations handy, but I've read it and I was at a talk Tufte gave on this subject, and my recollection of it is rather different. Without directly criticizing Feynman, Tufte actually comes up with a significantly superior analysis of the root cause of the disaster. Feynman spread he blame around many places, finding bad science, bad engineering, inaccurate statistics, poor procedures and documentation, politics influencing design, and most importantly and famously, a disconnect between management and engineering leading to overconfidence. Everything he found is right. But Tufte took the analysis one step further and came up with a completely convincing "one point where it all went wrong." That point was the inability of the booster rocket contractor's team to effectively present information.

The day before the Challenger's final launch, the team that designed and manufactured the booster rockets called Mission Control and said that they thought the launch should be aborted because an O-ring on a booster would be likely to give out due to cold and cause the Challenger to explode. This team was not previously known for being overly cautious; in the previous history of the shuttle program, they had never before recommended aborting a mission. The next day, the challenger launched and the booster rocket blew up exactly the way the team that made it said it would.

This seems like an inconceivable oversight on the part of Mission Control. When the team that designed the rocket told them it was going to blow up, how could they possibly go ahead and launch? The hubris, the pride, the thick-headed showmanship.

Well, Tufte dug into this and found out exactly what happened. Mission control told the rocket team to prepare a presentation about why they thought it would go wrong. The team did so and presented that to Mission Control. Tufte interviewed many people about the specifics of that meeting and actually managed to reassemble the original slides shown during the talk. And anyone viewing the information presented by the booster rocket team to Mission Control will have trouble faulting Mission Control, because the presentation was absolutely incomprehensible.

The booster rocket team's argument was supposed to be that for each previous launch, the amount of subsequent damage found in the O-rings was inversely proportional to the temperature at launch. They had all the data. They were all scientists and engineers. Tufte used their data to construct a graph of O-ring damage vs. launch temperature. Showing that graph and the weather forecast for the launch day to anyone in charge would have gotten the mission cancelled in a second. But the team, that was there to argue that low temperatures correlated with O-ring damage, never presented a single intelligible piece of data demonstrating that, even though they had all that data with them. Instead, they showed a chart of O-ring damage vs. launch date, and another chart several pages later with temperature vs. launch date.

I've read Adventures of a Curious Character and have the utmost respect for Feynman. Every problem Feynman outlined in his analysis was a real problem that NASA should fix. But none of it really pinpointed the exact cause of the disaster. Feynman mostly chalks the failure to postpone launch to management's disconnect from engineering, from their mistakes and lack of understanding and therefore overestimating the safety of the shuttle. This puts the blame in the wrong place. The managers were no where near being so overconfident that when the engineers who designed the part that failed knew it would probably fail in exactly that way and tried to halt the launch, they'd just brush them aside and go ahead with it. They listened carefully; the engineers had data that would make a great case, but it was presented so incompetently that no one at that meeting would have thought they had a case at all, they simply appeared to be overly cautious, because they did not present any data demonstrating their point.

Re:Brilliant analysis of brilliant analysis

[sphealey]

=== I've read Adventures of a Curious Character and have the utmost respect for Feynman. Every problem Feynman outlined in his analysis was a real problem that NASA should fix. But none of it really pinpointed the exact cause of the disaster. Feynman mostly chalks the failure to postpone launch to management's disconnect from engineering, from their mistakes and lack of understanding and therefore overestimating the safety of the shuttle. This puts the blame in the wrong place. The managers were no where near being so overconfident that when the engineers who designed the part that failed knew it would probably fail in exactly that way and tried to halt the launch, they'd just brush them aside and go ahead with it. They listened carefully; the engineers had data that would make a great case, but it was presented so incompetently that no one at that meeting would have thought they had a case at all, they simply appeared to be overly cautious, because they did not present any data demonstrating their point. ===

By his own admission, after he finished with the Computation Group during the Manhattan Project Feynman never managed anyone or anything and he had no desire to do so. I can respect that, but it does also mean that he never faced the situation of needing to make a management decision in a situation with incomplete information (but it is always incomplete...) and competing pressures (there are always pressures) including political factors (there are always political factors...). As a guide to system problems his report was brilliant but it always struck me as being a little too late-Dilbert in its overall conclusion.

sPh

Re:Brilliant analysis of brilliant analysis

[redelm]

Sorta. The things that failed were called "O-rings" but have nothing in common with proper O-rings (viscoelastic differential pressure seals). Those things leaked every time, while real O-rings never leak when clean and in good condition. The things that failed are more like packing, which must leak to work.

The real problem was the closure design was ripped off from a Hahn & Clay patent which the NASA and contractors did not understand and implemented horribly. The large-diameter closure was supposed to be a three-piece floating (self-centering) design. Apparently to save fabrication cost, it was done as a two-piece closure (non-centering) and worse, with the gap was facing in a hazardous direction.

Sure, initial temperature could easily play a role by causing shrinkage and larger-than-usual packing gaps. But it wasn't some sort of brittle fracture since I very much doubt the brittle transition temperature of the packing material was anywhere as high as 30'F. More usual is 0'F and below.

Re:Brilliant analysis of brilliant analysis

[Anonymous Coward]

I've been to Tufte's presentation on the Challenger disaster. The O-ring damage vs. launch temperature graph that he created exemplifies everything he complains about. I just pulled out my copy of his book just to make sure I have my facts right.

He used a "damage index" he created to quantify how bad the damage is based on NASA reports. Nowhere does he define how he created this index-how he decided what value to assign to what type of damage. This makes me very weary of this graph. Data can be manipulated very easily with weight factors to lead the audience to a certain conclusion.

Second, based on his damage index, at 70 and 75 degrees, three different flights experienced as much damage as some of the coldest temperature flights. If you delete the one low-temperature point from his graph, you have absolutely no trend in the data. I'm not sure what that would say if statistical analysis of all this. The human mind can extrapolate to identify trends where there are none. All I do know, from listening to his presentation and talking to the man is that his conclusion are based on hindsight and bias.

The loss of the Challenger, in my opinion, is mostly based on management pressures. If I recall correctly, one engineer at Thiokol actually quit in protest when the decision to launch was made. The slides for the presentations were poor and possibly misleading, but Tufte leaves out one important aspect of any presentation. You don't just throw slides up on a screen, you PRESENT the information on them, describe it, and provide insight not stated on the slides. Using his own jargon, presentation slides have a very low information density. Conferences and meetings would be completely useless if you didn't have a speaker interacting with the slides. The slides are more of a guide of what is to be discussed and a way to disseminate graphical data to an audience, which always needs explanation.

Tufte made some good observations about the presentations used to make the decision to launch that day such as lack of traceability of the authors, but I can't agree with his overall assessment.

Re:Brilliant analysis of brilliant analysis

[Phat_Tony]

I'm not qualified to assess the objectivity of his "damage index," but as he points out, a simple re-ordering of the data they actually presented is pretty convincing. You don't need his damage index at all, and his point stands. You can show damage vs. temperature representing both damage and temperature exactly the way the booster rocket team actually presented them at that meeting, and it's still convincing. Out of data from 46 launches, 8 had significant damage. Of those eight, five of them were in the seven coldest launches. None were in the 11 warmest launches. All three of the coldest launches had damage. With no attempt at all to categorize the severity of the damage, the a simple linear curve fit still shows a strong correlation between low temperature and damage.

Also, Tufte had interviewed people from both the management and engineering side who were at that meeting, and read notes and a summary of the meeting, and the analysis of the meeting from the Rogers Commission. The booster rocket engineers never presented their case in speech any more than they did in the graphs. They simply didn't have their information organized, in their graphs, in their talk, or in their heads. Any engineer or scientist should have been able to see that the point they were trying to convey was that launch temperature correlated to o-ring damage, and therefore they should show the correlation between launch temperature and o-ring damage, which they never really attempted to do in any way. Sure, management should have realized how disorganized their presentation was and sent them back to come up with some organized data, but it was the engineers job to present the case that they had a legitimate concern, and they completely failed to do so, despite having in their hands all the evidence they needed.

Re:Brilliant analysis of brilliant analysis

[AdamHaun]

When I was in college I took an ethics class that discussed some criticisms of Tufte's critique of the Morton Thiokol engineers involved in the Challenger launch decision. Here's a paper on it:

http://people.rit.edu/wlrgsh/FINRobison.pdf

Very interesting read.

Working Mirror

[winkydink]

http://www.networkmirror.com/LBKPk3ml3LEozZTj/duartes.org/gustavo/blog/post/2008/02/20/Richard-Feynman-Challenger-Disaster-Software-Engineering.aspx.html

Chartered engineer status

[Martin Spamer]

The biggest problem is most software developers are NOT chartered professional software engineers, so have no personal, professional and legal responsibility for their work. That is why IT is full of cowboys and trust is nearly none existent. Software Engineers must become a chartered only profession, so that people who are not chartered are not allowed to practice.

To qualify as a Professional Engineer we should place good practice above short term gains. Professional Engineers should be truthful and objective and have no tolerance for deception or corruption. Professional Engineers only work in areas were they are competant. Professional Engineers build their reputation on merit and their skills through continual learning and the skills of their charges through ongoing mentoring.

We wouldn't have to put up with the shoddy work of cowboys, because they wouldn't be allowed to practice. We wouldn't have to put up with orders that counteract professional ethics or good practice, because legal responsibility trumps commercial pressures. The professional wouldn't be undermined by fast to market but poor quality work. We could place trust in third party tools, software & services and we would not have to put up with EULA that diavowed responsibility for damage.

Re:Chartered engineer status

[Anonymous Coward]

Great idea...in theory...

Unfortunately it fails miserably in practice.

There WAS an attempt to build professionalism into computer programming. In the late '70s and '80s there was a full certification process created. The ICCP was built across all of the computer "societies" of the time, and was an educational-based group that pushed certifications. The intent was to make computer certifications the equivalent of a CPA for accountants.

The problem is, about the same time, the PC rolled around. All of a sudden it became possible for any John Doe to start writing "programs". It was no longer necessary to make a multi-thousand dollar investment just to get into the game. And as expected, 99% or more of what was produced was crap, but 1% proved to be very useful. And a whole new industry was born.

Then the "professionals" of the day found themselves competing with "off the shelf" software that was "good enough" to do certain things. And it has continued ever since.

Computer programming does not require a significant investment of anything more than time. And lots of people have time on their hands.

As long as the entry level remains so low, it will be impossible to put the genie back into the bottle. So software never will become the same type of "profession" that engineering is.

Re:Chartered engineer status

[dubl-u]

Software Engineers must become a chartered only profession, so that people who are not chartered are not allowed to practice.

This is a reasonable theory, but I think it's wrong in practice for a few reasons:

1. Most software is not life-critical. much engineering is.
2. Scale matters. You don't need to be licensed to build a doghouse or install cabinets. Only some software development is of the scale where quality practices matter.
3. Practice is quickly changing. For example, agile methods appeared circa ten years ago, and are just now becoming popular. A rigid professional standards process wouldn't allow necessary change.
4. 
   
   For now, because the costs of bad software are generally more direct and turn up more quickly, I think licensing isn't necessary yet. A failing bridge kills the people on it, but a failing bank software project only harms the bank's profit margins. They'll learn. Eventually.

Re:Chartered engineer status

[MariusBoo]

wtf? Every time somebody posts this idea it is modded insightful and people seem to agree. Am I missing sometime? This is Slashdot, I thought we wanted to be cowboys. I know this is why I got into programming: because I can get a computer and get to work NOW doing what I like. No certification, no asking other people if they'll allow me to program, no shit. Just code. Am I alone in this? Does everybody whant to form guilds now to keep the competition out? What gives?

Fatal Defect

[Anonymous Coward]

"Fatal Defect" by Ivars Peterson. A good read.

Time once again for the rejoinder, "Doctors bury their mistakes. Engineers read about theirs in the headlines."

I know someone who worked on the O rings

[CrazyJim1]

They said that the management at NASA didn't want to cancel the flight of the challenger because it was such a high profile launch even though they were warned about the O rings.

Re:I know someone who worked on the O rings

[rholland356]

You know someone who worked on the O rings. 20+ years ago. Add another 10 years of career work to even get to the point where they could be allowed to work on the shuttle O-rings. So, 30 years work plus 24 years education (masters degree, minimum). That someone you know is in his mid-fifties, most likely.

He is your father, luke!

And you are correct in saying that in the decision to launch, momentum and public relations carried too much weight. This was all well documented after the fact, of course. So, you don't actually need to know someone to learn easily the results of the investigation.

But hats off to your father, anyway! ;-)

yeah, right

[mapkinase]

May be there will be some sunny day when I will listen to what Linus Pauling says about vitamin C, what Fomenko says about history and what Richard Feynman says about programming.

But that day is not today.

Re:yeah, right

[FrenchSilk]

Richard Feynman never said anything about software engineering, to the best of my knowledge. Did you read TFA? But should Feynman have commented on software engineering, I for one would have read his comments with the utmost interest. Feynman had extraordinary intelligence and perception and used both in whatever interested him. And his interests were exceptionally varied. Whatever the topic, Feynman's comments are almost always insightful, interesting, and original. Would your same close-minded attitude stop you from reading anything Feynman had to say about Mayan hieroglyphs, for example? What would a physicist know about that? Or molecular biology. Or cryptology. Yet Feynman made significant contributions in all those areas. I suggest you read some of his semi-autobiographical books, such as "Surely You're Joking, Mr. Feynman!" and "What Do You Care What Other People Think?". I think that you might change your opinion as to whether you would deign to consider and value the ideas and opinions of Richard Feynman on topics outside his formal academic area.

Re:yeah, right

[mapkinase]

"Did you read TFA?" Do you mean TSA (the slashdotted article)?

He probably did not. Please consider my comment as an illustration of a more general idea than plain bashing aforementioned scientists (love that too, by the way...)

Re:yeah, right

[The_mad_linguist]

Turns out Pauling was at least partially correct, but the vitamin C has to be injected to get concentrations that are anywhere near effective.

Re:yeah, right

[Breakfast Pants]

Feynman worked closely with Stephen Wolfram. Feynman did a lot of work on reversible computing. Feynman managed a group the computing center during the development of the A-Bomb. But go ahead, read some random blog from someone who wrote a web widget that shows the weather.

Re:yeah, right

[mapkinase]

"random blog from someone who wrote a web widget that shows the weather." You nailed me, man. That was a knock out. :-)

Feyman died before Linux and world-wide-web

[peter303]

Not that his comments arent still relevant.

Re:Feyman died before Linux and world-wide-web

[Anonymous Coward]

A shame yours aren't.

Your heart's in the right place, but...

[Mariner28]

Your heart's in the right place, but it would not and cannot work.

Why? Simply - an excess of demand and a shortage of resources. There is simply too much demand for software development and there aren't enough Computer Science curricula in existence to meet that demand.

And this is coming from a degreed engineer. Not a licensed professional, however. Yeah, I took and passed the EIT, but never went for the PE. Why? In my original field, telecommunications, there never was any requirement at any of my employers to be a registered PE.

Granted, there are tons of people out there who confuse an MIS degree with a Computer Science or Computer Engineering degree. And if you hire an MIS grad to help develop the next whiz bang OS, well, chances are it won't work out. It might, but the odds are against you...

Re:Your heart's in the right place, but...

[greyhueofdoubt]

In addition, you can 'engineer' software in your mom's basement. You can't exactly learn to build dams as a teenager and cobble one together in mom's basement, and then kill a bunch of people when your shoddy work crumbles. It's easy to charter traditional engineers because their projects are often visible and overseen by regulatory agencies. Homemade software is not. You might as well try to ban bad actors or bad singers.

-b

Therac-25 - fatal software flaws

[seven of five]

An example of flawed control software leading to fatalities: http://en.wikipedia.org/wiki/Therac-25

Re:Therac-25 - fatal software flaws

[BitterOak]

Actually, I would classify that as a hardware, not a software problem. Lack of hardware safety interlocks was the real problem. That is why buggy software had fatal consequences. In many industrial settings where safety is an issue, the safety devices are generally not completely under software control, but incorporate hardware interlocks to ensure life-threatening conditions do not occur. Heck, even consumer microwave oven doors have a hardware interlock, as do many other appliances. Safety shouldn't be left up to software unless absolutely necessary. In the case of the Therac, it wasn't necessary. A simple interlock could have limited the power output depending on whether the device was in electron or photon beam mode.

Re:Mirror - original site now working

[gustavoduarte]

I got the site back up. It should be working now. I never imagined this would end up on Slashdot.

Re:Working Mirror - Original site now working

[gustavoduarte]

Thanks a ton for setting these up. I got the site back up. It should be working now. I never imagined this would end up on Slashdot.

My favorite line...

[MilSF1]

"The computer system is very elaborate, having over 250,000 lines of code." Wow, I've helped write PHP applications that have more code then that. Of course , that was all buggy to hell too.

Re:My favorite line...

[Anonymous Coward]

If you're writing 250 thousand lines of any scripting language for a single application then you're doing it wrong.

Consider also that this is 60's technology and probably written in assembly language. That code probably fills a ridiculously huge 8K memory bank.

Re:My favorite line...

[Araneas]

Running in core memory. Mind-boggling.

Software Engineers != Engineers

[Anonymous Coward]

Software Engineers [in Canada anyway] can't legally be called engineers, unless they are licenced by the PEO [Professional Engineers Organization].

It requires an accredited Engineering program, with the same math, science and engineering courses that civil/electrical/chemical engineers take.

Anything else is just a simple developer/programmer/analyst/code monkey.

Engineers are responsible to a central body, which can revoke licences, impose judgements, etc.

Who are programmers responsible to? Their managers? What oversight exists?

The slogan of the engineer is 'If I don't build it right, people could die", while the slogan of the programmer is:

"if I don't build it right, I'll release a service pack, bug fix"..

physics is not engineering

[nguy]

Physics is not engineering. If you get things wrong in physics, usually, nothing happens except maybe an angry letter to the editor. Physicists regularly produce incomplete or even contradictory theories, and nobody dies. Physics doesn't have to interface with people; when coming up with a theory of quantum gravity, you don't have to worry about people pushing the wrong button. And the complexity (in terms of variables, equations, etc.) of all of theoretical physics taken together is probably still less than that of a single big software project.

Re:physics is not engineering

[NewbieProgrammerMan]

I think you greatly underestimate the complexity of the ideas you need to have under your belt to understand all of theoretical physics.

Re:physics is not engineering

[Actually, I do RTFA]

Physics is not engineering. If you get things wrong in physics, usually, nothing happens except maybe an angry letter to the editor. Physicists regularly produce incomplete or even contradictory theories, and nobody dies

Ironic that you would post that in a topic about Feynman. While he was a brilliant theoretical physicist, his first job was designing the analog computing machines that launched artillery shells for the Army, and he had a part of building the atomic bomb. He was the guy who used then-theoretical physics to come up with safety parameters at Oak Ridge (where they were processing the Uranium.) So, I guess you could say when the physics went right, a lot of people died.

Re:physics is not engineering

[Actually, I do RTFA]

I think you greatly underestimate the complexity of the ideas you need to have under your belt to understand all of theoretical physics.

Yeah, my boss thinks anything he doesn't understand is easy as well.

Re:physics is not engineering

[Anonymous Coward]

None of that is the kind of experience you need for large scale engineering.

Re:physics is not engineering

[nguy]

I think you greatly underestimate the complexity of large engineering projects. They may not be intellectually as challenging as theoretical physics, but they have an enormous amount of detail.

Re:physics is not engineering

[NewbieProgrammerMan]

I've worked on a few medium-sized software projects, so I have a little appreciation for how complex big software projects can be. Please note that I didn't say anything about software or engineering projects not having lots of detail, or even that they can't rival physics problems in complexity. I just thought it was silly for (I presume) a non-physicist to suggest that the *entire* field of physics is less complex than a big software project.

Re:physics is not engineering

[nguy]

I've worked on a few medium-sized software projects, so I have a little appreciation for how complex big software projects can be. Please note that I didn't say

Medium sized software projects aren't the same as the complex engineering (software and hardware) projects that occur in space and defense. You simply can't extrapolate from one to the other.

to suggest that the *entire* field of physics is less complex than a big software project.

You're a sloppy reader; that is not precisely what I said. What I said should be pretty self-evident if you do a back of the envelope calculation. Keep in mind that every line in a computer program amounts to an equation, and every part (down to the screw) is a complex system, subject to numerous physical and legal constraints that many man hours of design have gone into. The fact that you don't even notice this complexity is because engineering manages it so well.

for (I presume) a non-physicist

Getting into pissing contests about qualifications on Slashdot is pointless. If you have a point, make it.

Re:physics is not engineering

[NewbieProgrammerMan]

Let's see, in your original post, you said:

And the complexity (in terms of variables, equations, etc.) of all of theoretical physics taken together is probably still less than that of a single big software project.

Which, if you want to be a lawyer about it, really doesn't mean anything: the weight of concepts you need to understand anything in modern theoretical physics is far more complex than the written representation of the theory, just as the weight of concepts you need to understand an avionics system is far more complex than the printout of the code and specs of said system. Now that I read it with my semantic goggles on, you were just comparing apples and oranges.

It wasn't my intent to get into a qualification pissing match, I just wanted to point out that what you were doing is equivalent to a physicist who once took an engineering or C++ course making an off-the-cuff comment that, "the complexity (in terms of circuits, software, assembly diagrams, legal considerations, etc.) of all of engineering taken together is probably still less than that needed to understand a single concept in modern theoretical physics." You're underestimating the depth of a field you know only a little bit about, and that was my point.

Re:physics is not engineering

[Anonymous Coward]

You don't know what you're talking about. Stop bullshitting.

Re:physics is not engineering

[NewbieProgrammerMan]

Golly, I've been told. You sure showed me not to challenge the opinion of an engineer on Slashdot!

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:As a software quality professional...

[TemporalBeing]

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. You can't say the same thing about software.

Well, actually you can. It's just a bit different since in mechanical engineering, you will have one that will specialize in bridges, and another in autos, etc; but management won't try to take a bridge engineer and make him design autos. Where as in Software, it is often the case that the software engineer with specialty X will be asked to do work that requires specialty in Y. Yes, to a degree there is an overlap - just like with the mechanical engineers - but often there is a vast difference.

So just like mechanical engineering a bridge is a bridge, but a bridge is not a car. Similarly an application is an application, but an application is not a device driver.

Re:As a software quality professional...

[gosand]

Well, actually you can. It's just a bit different since in mechanical engineering, you will have one that will specialize in bridges, and another in autos, etc;

I'll take my bridges desinged by civil engineers, thanks. But I get what you meant. :)

Re:As a software quality professional...

[Anonymous Coward]

Comparisons of methods in software and construction business mostly are based on
idealistic views of the "other side". Reading what M.Fowler says in the foreword (intro?) to his pattern book resembles what students of engineering disciplines tell their parents when asked what they do. I started as a civil engineer some decades ago
and am doing my finishing rounds in information technology now. Believe me: the
difference is by far less than described by most discussion participants (I originally
was a bit fed up by the ways the construction industry did their job and hoped for better on the other leg - at least I would not describe it as worse). BTW: David
Parnas already gave code to uninitiated developers to let them find out what the code
would do, in the 70ies I think. - It is not in the methods but in ourselves (although
deciding on the tools is important too, of course). Cheers!

I didn't read TFA, but...

[cuantar]

This story is about Feynman, so it needs to be tagged "richardfeynmanisgod."

Re:Proximate cause vs ultimate cause

[Anonymous Coward]

There was a point that Feynman missed, which is that the SRB support mechanism, a support at the top and bottom, created a single point of failure of the entire system. If there had been a third support in the middle, the burn through and failure of the bottom support would not have caused that SRB to rotate into the main tank. Feynman found the proximate cause in the failure of the 'O' rings, but not the design flaw that was the ultimate cause.

News sure travels slowly

[syousef]

The blog entry is dated today.
The link to Feynman's appendix to the Rogers Commission is a link dated 1996.
Feynman died Feb 18 1998.

So we're talking about something over 10 years old that a blogger has added a few personal observations to, and it's linked in as slashdot news.

Re:News sure travels slowly

[CaptainCarrot]

And not very much in the way of personal observation at that. It was Feynman himself who made the comparison to best-practice software engineering. All TFA was really doing was pointing out that we already know what best-practices are for critical applications and that we generally don't use them. To anyone who develops software, who was interested enough in either the Challenger explosion or Feynman himself to have read it already, it's not news.

Someone make sure NASA knows RAM is cheap now...

[TheQuantumShift]

From the linked Feynman Essay:

"There is not enough room in the memory of the main line computers for all the programs of ascent, descent, and payload programs in flight, so the memory is loaded about four time from tapes, by the astronauts."

Since I've had such stellar success with tapes and drives made this century, I can't image trusting landing the shuttle to some made 20+ years ago...

why were the boosters built in sections ..

[rs232]

01. Don't build solid fuel boosters in sections.

02. Don't build them out of state so they have to be sectioned to transport by rail.

03. Don't compromise design so as to get some politians vote for funding, forcing you to site the solid rocket booster in his state.

04. Don't ignore safety concerns from your own engineers

05. It don't take a nuclear physicist to figure this out ..

Re:why were the boosters built in sections ..

[icegreentea]

To be fair, I have a feeling that almost all rocket boosters once they reach a certain size have to be built in sections. And maybe there just aren't any companies in Florida that can build such rockets. Engineering ethics is a constant trade off. Some element of risk must be accepted.

Re:why were the boosters built in sections ..

[Breakfast Pants]

Don't build them out of state so they have to be sectioned to transport by rail. Apparently you don't know anything about congress.

Columbia Crashed 5 Years Ago Feb 1st.

[genegeek]

Maybe it's the election, but I had thought I was watching plenty of news lately. This post made me look up Columbia and I see that the 5th anniversary of its crash was Feb 1st, 2008. Funny thing is, I didn't hear a thing about it then. Did anyone else? Or was this ignored by the media in the runup to Feb 3rd (superbowl) and Feb 5th (super Tuesday)? Seems that NASA was reminded with this disaster to pay attention to the Feynman suggestion that shuttle failures will happen on the order of 1% of the time, as suggested by its engineers. Glad the Mars landed proposed by Bush still has time to be well-designed. ;) BTW, the Iraq war also started about 5 years ago, on March 19. Maybe that event helped to squelch public morning for Columbia at the time. Sure seemed like it wasn't in the headlines for long. Or maybe, like me, everyone was just to sad to be reminded of Challenger and didn't want to think about Columbia.

Faynman Videos.

[ip_free]

If you like Faynman here are some of his lectures. http://vega.org.uk/video/subseries/8

Re:Someone make sure NASA knows RAM is cheap now..

[PhxBlue]

If it ain't broke, don't fix it. The software, at least, ain't broke.

Feynman was hoodwinked in the Challenger debacle

[itsybitsy]

If I recall from watching video interviews with Richard Feynman he said that the general who got him involved in the challenger accident investigation already knew the problem about the O-Ring. He asked (or ordered?) Richard to present it to the panel. Richard didn't like being played by the political powers that be. The general thought that people would listen when they saw it demonstrated by Feynman and heard it from Feynman.

I suppose the powers that be thought it would be good to hoodwink Feynman for a change.

The interviews with Richard Feynman are fascinating to watch. If you find the one where he talks about the challenger accident please add the link with a reply to this comment. Thanks.
http://youtube.com/results?search_query=feynman&search_type=

"Engineering discipline" talk by Marcus Ranum

[whamett]

Marcus Ranum has an interesting talk (MP3) in which he discusses Feynman's Challenger commentary at some length in the context of designing reliable/secure software systems.

The talk gets off to a bit of a rough start (see Ranum's comment below), but contains much insight and makes a lot of sense before long. Highly recommended for those in the software development field, where the approach is often 'throw it together, then poke at it and patch it until it stops obviously breaking'; the rigour Feynman & Ranum describe may be overkill for some systems, but exposure to this other approach can help make most of us better developers. I found it helpful, anyway—your mileage may vary.

This was an improvised dinner address, delivered without powerpoints and after a few too many bottles of beer. [...] The objective of this talk was to take the high ground with respect to treating computing as an engineering discipline, instead of the kettle of kludges that it has become. I realize it's very very idealistic stuff.

Not 100% correct

[Gr8Apes]

The following three I know were the result of human involvement and decisions, not engineering mistakes and are documented:

• Chernobyl: manager and employees being idiots. No engineers involved. When you manually override safety systems....
  
• Hyatt Regency: contractor changed "unworkable" design without engineer approval. The approved blueprints show a different design.
  
• Three Mile Island: employees overrode programmed corrective actions causing the meltdown. Engineers had it right.
  

I don't know about the rest of them. Yes, I'm an engineer. Two of those were covered in my engineering class.

Re:Not 100% correct

[turbidostato]

"The following three I know were the result of human involvement and decisions, not engineering mistakes and are documented:"

Are you sure those are not engineering mistakes? If you ask a user to remember half a dozen, ten characters, unpronunciable password, they *will* stick them to a post-it on the monitor, and that's an engineering problem. If you burden field technicians with unproper unergonomic "safe" mechanisms you know they *will* find workarounds, and that's an engineering problem. If you leave out the project management cycle on-field implantation, there will appear on-field problems that *will* be managed out the project management cycle and that's an engineering problem too.

If you put the self-destruction device button just alongside the lights power switch, it won't be user's fault when he presses it by mistake: it's engineering at fault. If you design a safety system that *mustn't* be overriden in any circumnstance but you design it so it *can* be overriden, it's engineering at fault.

Re:Not 100% correct

[Gr8Apes]

Are you sure those are not engineering mistakes? If you ask a user to remember half a dozen, ten characters, unpronunciable password, they *will* stick them to a post-it on the monitor, and that's an engineering problem. That's not an engineering problem. That's a policy problem. Or would you call someone dying by driving into a bridge pillar at 120mph an engineering problem? (Keeping the person alive that is, keeping the bridge pillar intact is an engineering problem that was addressed successfully, as I've never seen a car damage a bridge pillar) Because something is possible doesn't necessarily make it an engineering "mistake". An engineering mistake is the foam on the space shuttle external fuel tank, or the first iteration of the V-22 Osprey's with composite bearings for the tilt rotors (don't know if they changed this - if not, expect more crashes) or the Tacoma Narrows bridge or any of a number of leaning buildings/towers. I know of at least 3 that I've personally visited. Something about building on sand and lack of proper foundations.... All are old though.

If you burden field technicians with unproper unergonomic "safe" mechanisms you know they *will* find workarounds, and that's an engineering problem. If you leave out the project management cycle on-field implantation, there will appear on-field problems that *will* be managed out the project management cycle and that's an engineering problem too. Your hypothetical tangents do not apply to any of the three situations presented.

At Chernobyl, a manager and some flunkies decided to run unauthorized "tests" that "failed" the first time because of safety devices. They then disabled those safety devices, and voila. The "test" itself was something that was cooked up by those morons.

The Hyatt was the result of someone going "That's too hard/impossible to build, let's change it". When building to approved blueprints, code states you do not change anything without a signature approval.

At three mile island, had they just let the computers do their thing, everything would have been fine. The employees didn't trust the computers, and overrode them. They did this at least on two separate occasions during the event, thwarting automated corrective actions that would have prevented the meltdown.

In all three cases, people went outside the well known, well documented processes because "they knew better". In two cases I'd say they expended significant effort to do so.

Re:Not 100% correct

[turbidostato]

"Or would you call someone dying by driving into a bridge pillar at 120mph an engineering problem?"

Of course not. Because it's out of the problem realm disallow pillar crashing, not because "human stupidity is not an engineering problem".

When something is well within the problem realm (passwords are to allow for safe authentication), policies *are* part of the engineering problem, and bad policies so much so. Regarding the safe auth problem, not thinking about some nuts stablishing a nuts policy that ends up with passwords on post-its *is* an engineering problem. Engineering is not just about "hard stuff that melts and mechanizes"; it's about people and safe procedures too.

"In all three cases, people went outside the well known, well documented processes because "they knew better""

No. In all three cases people went outside the well known, well documented processes because *they could* when due to problem nature and environment was well within engineering specs that they shouldn't be able to do what they did. Even the Hyatt case would have been avoided with such a simple ingeneering practice as "the engineer should have been there" since, by definition, any singular building is a prototype.

Re:Not 100% correct

[Gr8Apes]

I'll condense this down to just the topic at hand, and not some esoteric discussion about passwords, as that is a wide open arena with many solutions.

No. In all three cases people went outside the well known, well documented processes because *they could* when due to problem nature and environment was well within engineering specs that they shouldn't be able to do what they did. Even the Hyatt case would have been avoided with such a simple ingeneering practice as "the engineer should have been there" since, by definition, any singular building is a prototype. You're wrong.

Let's rephrase that:
You're wrong.

There's not a system made that cannot be gotten around. Chernobyl was a classic case.
Three Mile Island was actually the result of engineers being forced to put in human overrides because the managers felt that computers needed a human hand guiding them.

Lastly, the Hyatt case solution you present looks obvious in hind sight, but the entire concept of signed plans arose precisely so the engineers wouldn't have to sit on their ass for 9 months while a building was built doing nothing and getting paid considerable sums.

So you: 0. Human Stupidity: 3.

Hint: hind sight recommendations to prevent a particular problem from arising is easy. It's also easily gotten around, or becomes ridiculously expensive and unmaintainable. That's why processes are put in place, and why there are repercussions for when someone steps outside of accepted and approved processes and things go badly, like in these three cases.

You can engineer something so well it never gets built, or put into place accepted uses and processes, and build it.

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:One of the first things a new staff member does

[greyhueofdoubt]

I appreciate the other thoughts in your post, but this:

>>When I feel the pressure is starting to cause situational ethics creep, I pull out Feynman's appendix...

is the best slashdot non sequitur I've ever read.

btw, I work on aircraft, too, and Feynman is a role model for me.

-b

Re:Feynman was hoodwinked in the Challenger debacl

[redelm]

Close enough. The things that failed were called "O-rings" but have nothing in common with proper O-rings (viscoelastic differential pressure seals). Those things leaked every time, while real O-rings never leak when clean and in good condition. The things that failed are more like packing, which must leak to work.

Initial temperature could easily play a role by causing shrinkage and larger-than-usual packing gaps. But it wasn't some sort of brittle fracture since I very much doubt the brittle transition temperature of the packing material was anywhere as high as 30'F. More usual is 0'F and below.

Re:Someone make sure NASA knows RAM is cheap now..

[ggwood]

From Feynman's book "What do you Care what Other People Think": "the comptuers on teh shuttle are so obsolete that the manufacturers don't make them anymore. The memories in them are the old kind, made with little ferrite cores that have wires going through them. In the meantime we're developed much better hardware: the memory chips of today are much, much smaller; they have much greater capacity; and they're much more reliable." (page 192 of my copy, it's in chapter called An Inflamed Appendix).

Yup, time to turn it in

[StCredZero]

Time to turn in your geek cred. There's a lot of references to many things, some of which are pretty high-minded cultural references. There's also very artful and clever references to comics, games, sci-fi, movies, anime, and concepts like the singularity.

Hint: the thing being tripped on isn't acid.

Genius

[8400_RPM]

Richard Feynman is one of the few intelligent people to walk to earth. Few know who was, but there are not many people through history more important.

Slashdotter Addon for Firefox Adds CC links &

[MCRocker]

As a side note, could someone make a grease monkey script to make all links frmo /. run through coral?

The slashdotter extension does that and much more.

Unfortunately, the new beta thread navigation feature on slashdot breaks some of the AJAX features like expanding hidden comments in-line without a page reload :( Of course, you can just turn off the beta and everything works as expected.

I think i missed this boat!

[socz]

But didn't everyone agree many years ago it was simply the o-ring that failed... as it had many times in testing... as it kept failing... because of crappy building materials and poor design?

i'm really sad i missed the big debate here but this is old news isn't it? What new light has been shed? We have footage of nasa testing the booster rockets blowing up on their sleds because of the o-rings. I don't recall having heard that the weather played a part, but the ports freezing up and failing o-rings was pretty much a constant throughout all ideas put on the table.

is TFA worth my time or have i picked up enough with comments alone?

one poster said it was about pressure from many sources -- they're right. Because of time lines, budget constraints and bad managerial choices the challenger happened. I hope they have learned enough to not repeat that... which is probably why they're returning to Apollo style rockets (which is retardeddedededded)

Just pointing fingers?

[daveisfera]

I agree with this completely (and I have seen minor versions of this in my job at a defense contractor), but I have to say that there's a certain amount of personal accountability that has to be taken by engineers/software developers(engineers)/anyone.

At times I have been pressured to get something done or let something pass, and sadly I have to admit that I've often given in. But as bad as this is, it's just as unethical for me to try and blame the problem solely on management/capitalism/any "invisible hand".

Re:Just pointing fingers?

[Grishnakh]

At times I have been pressured to get something done or let something pass, and sadly I have to admit that I've often given in. But as bad as this is, it's just as unethical for me to try and blame the problem solely on management/capitalism/any "invisible hand".

I disagree.

Suppose you're a minimum-wage ditch digger, and your boss orders you to dig a ditch in a graveyard, disturbing the graves. If you refuse to do the job, you'll get fired and replaced immediately with someone else who will. Then you'll have to explain to your family why they can't eat.

Being a software engineer is no different. If you don't do the job the way they want it, you'll be replaced. Control is entirely in the hands of management.

This isn't like building buildings or bridges, where engineers typically work for a high-priced consulting firm, and are bound by rigorous ethical standards, government rules, and the potential of being sued or even imprisoned if they screw up. In software, engineers are just paid peons; they do what they're ordered to, or else. If you don't like it, you better look for another career. You could try to start your own consulting firm with rigorous quality and ethical standards too; let me know how successful that is in 5 years. My guess is that you'll go out of business without a single customer. If you could do such a thing successfully, your only customers would be military, government, aviation, etc. contracting for safety-critical jobs, not companies that want web apps or Windows apps written.

Convenience trumps reliability

[Anonymous Coward]

I did contract work as a Software Developer for an airplane engine manufacturer (among other things this DOD contractor does). After I pushed a new CAD module to Dev, I was shocked to find out how the software was configured to run.

You see, this very important company wanted their software to be "always available" - even when a specific server or database wasn't available. So the script that ran the program would look for its (50+) supplementary modules in Prod. If a specific module wasn't available in Prod it would try connecting to QA, if QA wouldn't work it would load from Dev. It did all this without prompting or even notifying the user that they weren't running "Prod level" software for all the components.

When I raised concerns that engine components were being developed using this fail-over strategy, I was stunned to discover that most of their software used similar startup scripts. I was also told repeatedly by the engineers that it didn't matter because "all modules have been tested and are production-ready, or the vendor wouldn't have released them to the public.".

They're still making engines, but there'll come a day when a component developed or tested using Prod software loads a Dev module and makes a deadly, untested calculation. Possibly very similar to computer errors that caused the Hartford Civic Center roof collapse.

I quit soon after, and I get very nervous when I fly on planes with those engines.

When money or reputation is involved, convenience trumps reliability far too often.

Read Angle of Attack by Mike Gray

[deltacephei]

The pressure from the government to beat those damned ruskies into space at all costs.

Angle of Attack is a magnificent read, both for the human side of the story, and the achievement of manned space flight from an inside engineering viewpoint. The at all costs dictum forced something else: the conscientious and conspicuous mandate to do things differently, fail and learn from it, and not stay in any comfortable ruts. There were no sanitary, emasculating powerpoint charts; instead stories of important people being called in at midnight to get to questions immediately. This is not to diminish the importance of ethics, but part of what came out of Apollo was thinking outside the box at all moments and not being tethered from doing so by management. Would that type of engineering today be seen as rogue and wasteful or brilliant? Indeed, how many places now truly allow development to occur in this fashion across all departments, despite the bullshit marketing speak spewed to investors and prospective employees? The global requirement of quick return of investment (measured in misleading ways, say lines of code per day for example) can stoke ethics problems, lead to a lot of CYA behavior, and squash innovative, careful, time consuming with little to show for it, thinking.

What do you care what other people think

[brajbir]

For more info, refer "What do you care what other people think".

The Blog is WRONG

[Anonymous Coward]

The blog entry fails to understand that Feynman was criticising the lack of testing during the construction of the engine to fit the "top down" design.

The point Feynman makes is that you *must test* at a very low level to gain surety about what you build out of the low level building blocks. i.e. one way of looking at it is that you need to verify that each function in libc (strcpy, etc) through manual inspection and then verifying they work through testing. Any change to that function requires a repetition of that process. Then as you build your program up around various libc functions (which you know are correct), you have to repeat that testing and verification step.

This process and testing does not mean that "bottom-up" design is what's called for, but rather when you build something, you need to test each component as you go along.

There is nothing wrong with stating the space shuttle engines must work for X hours in a design spec, but if you do not do testing on the components to verify that, then you have a problem with the assembled unit.

Re:Feynman was hoodwinked

[itsybitsy]

Ah, yeah, I know what they say failed on the shuttle.

The aspect that I was pointing out was that Feynman said that he was told by a general what failed and to present it at the public presentation of the investigating panel - which he then did. What Feynman said when interviewed about it was that he didn't like the "answers" being feed to him (I'm paraphrasing as I can't find the video clip at the moment) by political people. He said that he felt "used" by them. In essence he felt "hoodwinked".

Like Engineering? NO WAY!

[JanMark]

> Software has much in common with other engineering disciplines

As a programmer, I go through life battling this view. I would agree to:
Software (development) has much in common with engineering of
first-time things.

Engineering is about how to create and how to reproduce. The two are
often confused, but very distinct. Building a house is mostly reproductive
engineering. Because software is easily reproduced, "building" software
usually is much more a N-time endeavor for a relative small N.

Clearly the space shuttle design was mostly pushing the envelope,
first-time engineering. In my opinion, in constructing the big engine,
too much reproductive engineering was utilized, where they should have
used first-time engineering techniques.

I think this point is maybe to subtle for non programmers, and therefore I
feel the need to oppose it.

The top-down approach is compatible with reproductive engineering, the
bottom(s)-up approach is better suited for most first-time development.

If only my managers would get that. :-)

Moores Law is bad for NASA

[elFisico]

Feynman writes in his appendix of the final report:

"The actual hardware is obsolete; for example, the memories are of the old ferrite core type. It is becoming more difficult to find manufacturers to supply such old-fashioned computers reliably and of high quality. Modern computers are very much more reliable, can run much faster, simplifying circuits, and allowing more to be done, and would not require so much loading of memory, for the memories are much larger." Interestingly this statement was quite true in 1986 but it is no longer true today. It is nowadays expensive to produce a microprocessor that is space-hardened due to the extremely small dimensions that are used in computer chips nowadays. The space shuttle computers are PDP-11, if I recall correctly, manufactured with discrete logic, maybe even discrete transistors, making them suitable for a high-radiation location as space itself. A single charged particle that hits a discrete transistor will not induce any errors while it might bring down a complete modern CPU.

If NASA were to replace the shuttle computers they would need to have their own CPUs manufactured with rather coarse structures, they simply cannot use any of the modern embedded processors. I'm not sure if designing and manufacturing your own CPU chip nowadays is really cheaper than custom-threading magnetic core memory...

Re:Moores Law is bad for NASA

[norwayjose]

The Shuttle uses 5 computers, all based on IBM 32 bit CPUs (see link below). You can rad-harden a general purpose CPU chip though it is an expensive process.

http://en.wikipedia.org/wiki/IBM_AP-101

Where is this all going?

[agentultra]

Okay, so applying the principles of engineering to software development is a good thing -- but what does it mean and where should I start?

I found the article a little hard to follow -- it didn't really lead me anywhere. The author pointed out this esoteric concept of the "bottom-up" approach which Feynmann believed was important; but the author failed to show me how he thought it would apply to software development. I only understood that we should apply it. I never really read in the article what this approach is and how to apply it to my practice of software development.

The article did well to point out the short-comings of software developers who did not take this approach, but it lacked the evidence to explain and support the author's theory.

The links he pointed to were more or less the same. I'm rather spell-bound by this. Am I to believe that the author's intent was to tell us that we should all think of software development as he does? Is that what will turn software development into the utopia thought it should be?

I do not disagree with the premise of the article; I just wish proponents of it were more clear in the practical application of their theory.

Afterall, that's the goal of engineering, is it not?

Re:Feynman was hoodwinked

[redelm]

Yes, I understand your point and I'm trying to support what might otherwise be seen as an extraordinary claim. One might wonder why "The General" would interfere. I was providing motive.

Even if it made it past design, those O-rings should have been red-flagged and fixed after the first test-firing of the SRBs showed leakage. They were not proper O-rings. The fact that it was not (perhaps for reasons of schedule or whatever) is somewhat culpable if not revealing a military (vs civilian) risk tolerence level.

Regarding TFA...

[dezert_fox]

The quotes by Feynman are great, but the actual article linked (the blog post) is one of the most spectacularly uninsightful things I've ever read. I don't think that dud has ever worked on any sort of engineering project, ever. Can we just link straight to the good stuff next time, and not to some retard's blog?

a good Feynman's quote... FTA

[Zarf]

... actually from Feynman's original article referenced by the linked article... a real gem:

For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. I think that says it all right there folks. And I think a lot of us who do engineering or "engineer" software for a living would like to wave this in the faces of our PHB's but the problem is your PHB doesn't know what reality or nature are and can't bring themselves to trust you who have dedicated your life to the study of those things.

The computer has a reality and a nature and software must live within those rules or risk the consequences.