Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Richard Feynman, the Challenger, and Engineering

CmdrTaco posted more than 6 years ago | from the this-is-not-warm-fuzzies-on-a-cold-morning dept.

Programming 217

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

cancel ×

217 comments

Sorry! There are no comments related to the filter you selected.

Huh? (1)

arizwebfoot (1228544) | more than 6 years ago | (#22489310)

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

Yeah, BUT... (1)

StCredZero (169093) | more than 6 years ago | (#22489530)

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 [dresdencodak.com] and you don't!

Re:Yeah, BUT... (1)

drharris (1100127) | more than 6 years ago | (#22489980)

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... (1)

RxScram (948658) | more than 6 years ago | (#22490274)

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

Re:Yeah, BUT... (1)

s_p_oneil (795792) | more than 6 years ago | (#22491108)

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... (2, Interesting)

TobyRush (957946) | more than 6 years ago | (#22492580)

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.

Feyman died before Linux and world-wide-web (1)

peter303 (12292) | more than 6 years ago | (#22490496)

Not that his comments arent still relevant.

External Pressures Ruin Engineering (5, Insightful)

eldavojohn (898314) | more than 6 years ago | (#22489314)

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 [wikipedia.org] 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 (0, Interesting)

Anonymous Coward | more than 6 years ago | (#22489456)

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 (5, Informative)

esocid (946821) | more than 6 years ago | (#22489946)

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 (1)

Rob T Firefly (844560) | more than 6 years ago | (#22489486)

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

Re:External Pressures Ruin Engineering (1)

homey of my owney (975234) | more than 6 years ago | (#22492480)

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 (5, Informative)

DBCubix (1027232) | more than 6 years ago | (#22489542)

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 (5, Interesting)

Sanat (702) | more than 6 years ago | (#22490620)

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 (1)

Radical Moderate (563286) | more than 6 years ago | (#22491672)

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 (2, Interesting)

MightyYar (622222) | more than 6 years ago | (#22491302)

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 (4, Informative)

russotto (537200) | more than 6 years ago | (#22491552)

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 (5, Insightful)

Vicious Penguin (168888) | more than 6 years ago | (#22489604)

> 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 (4, Insightful)

Protonk (599901) | more than 6 years ago | (#22489800)

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 (1)

Tyberius (944471) | more than 6 years ago | (#22492030)

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 (2, Interesting)

Protonk (599901) | more than 6 years ago | (#22489640)

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 (0)

Anonymous Coward | more than 6 years ago | (#22492080)

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 (2, Informative)

Yvanhoe (564877) | more than 6 years ago | (#22489714)

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 (1)

drinkypoo (153816) | more than 6 years ago | (#22490558)

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 (1)

stubob (204064) | more than 6 years ago | (#22491260)

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 [blogspot.com]

Re:External Pressures Ruin Engineering (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22489962)

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.

You gotta have some pressure. (0)

Anonymous Coward | more than 6 years ago | (#22489964)

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! (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#22490038)

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.

Re:External Pressures Ruin Engineering (1)

ChrisA90278 (905188) | more than 6 years ago | (#22490136)

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 (2, Insightful)

somersault (912633) | more than 6 years ago | (#22490280)

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 (1)

Knara (9377) | more than 6 years ago | (#22490402)

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 (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22490642)

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 (1)

somersault (912633) | more than 6 years ago | (#22490670)

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 (1)

Knara (9377) | more than 6 years ago | (#22490842)

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

Re:External Pressures Ruin Engineering (1)

Knara (9377) | more than 6 years ago | (#22490872)

Oh, and this AC [slashdot.org] for that matter.

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

Re:External Pressures Ruin Engineering (1)

ccguy (1116865) | more than 6 years ago | (#22490468)

"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 (1)

uncqual (836337) | more than 6 years ago | (#22492586)

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 (1)

theskipper (461997) | more than 6 years ago | (#22490474)

* 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 [wikipedia.org] . 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 (1)

Dan Posluns (794424) | more than 6 years ago | (#22490506)

This is precisely why engineers in Canada have both a professional association [engineerscanada.ca] and what was deemed to be a "suitably dignified" Ritual of the Calling of an Engineer [wikipedia.org] that was devised by Rudyard Kipling [wikipedia.org] in response to the Québec Bridge disaster [wikipedia.org] 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 [ironring.ca] 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 (1)

ceoyoyo (59147) | more than 6 years ago | (#22490894)

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 (0)

Anonymous Coward | more than 6 years ago | (#22491860)

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 (2, Insightful)

Omnifarious (11933) | more than 6 years ago | (#22491054)

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:Proximate cause vs ultimate cause (0)

Anonymous Coward | more than 6 years ago | (#22492094)

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.

Re:External Pressures Ruin Engineering (1)

dubl-u (51156) | more than 6 years ago | (#22492306)

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.

wow (4, Funny)

loconet (415875) | more than 6 years ago | (#22489394)

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 (1)

EricWright (16803) | more than 6 years ago | (#22489450)

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.

A future essay... (2, Funny)

StarfishOne (756076) | more than 6 years ago | (#22489454)

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

Mirror (2, Informative)

fishdan (569872) | more than 6 years ago | (#22489480)

http://duartes.org.nyud.net/gustavo/blog/post/2008/02/20/Richard-Feynman-Challenger-Disaster-Software-Engineering.aspx [nyud.net] 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 (1)

Chris Mattern (191822) | more than 6 years ago | (#22489600)

Slashdotted as well.

Working Mirror (2, Informative)

winkydink (650484) | more than 6 years ago | (#22490070)

Re:Working Mirror - Original site now working (1)

gustavoduarte (1243006) | more than 6 years ago | (#22491336)

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.

Re:Mirror - original site now working (1)

gustavoduarte (1243006) | more than 6 years ago | (#22491232)

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

slashdotted (1)

esocid (946821) | more than 6 years ago | (#22489532)

already?

Faster, Better, Cheaper (5, Insightful)

Protonk (599901) | more than 6 years ago | (#22489538)

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 (0)

Anonymous Coward | more than 6 years ago | (#22489960)

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 (1)

Protonk (599901) | more than 6 years ago | (#22490138)

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 (1)

DaPhilistine (710883) | more than 6 years ago | (#22490348)

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 (1)

avandesande (143899) | more than 6 years ago | (#22490444)

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.

Tag on to a famous essay... (5, Interesting)

sphealey (2855) | more than 6 years ago | (#22489540)

(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... (2, Interesting)

pilgrim23 (716938) | more than 6 years ago | (#22489678)

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.

Brilliant analysis of brilliant analysis (1)

dazedNconfuzed (154242) | more than 6 years ago | (#22490046)

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 [amazon.com] . 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.

WWRFD (0)

Anonymous Coward | more than 6 years ago | (#22489590)

What would Richard Feynman do? [wellingtongrey.net]

Hm. (5, Insightful)

gardyloo (512791) | more than 6 years ago | (#22489630)

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 [ranum.com] ), 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. (2, Insightful)

Protonk (599901) | more than 6 years ago | (#22489706)

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. (3, Informative)

gustavoduarte (1243006) | more than 6 years ago | (#22489812)

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. (1)

Protonk (599901) | more than 6 years ago | (#22489910)

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. (1)

gustavoduarte (1243006) | more than 6 years ago | (#22489934)

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

Re:Hm. (1)

Protonk (599901) | more than 6 years ago | (#22490226)

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

Re:Hm. (1)

gustavoduarte (1243006) | more than 6 years ago | (#22491412)

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

My favorite line... (1)

MilSF1 (710927) | more than 6 years ago | (#22491384)

"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... (0)

Anonymous Coward | more than 6 years ago | (#22492308)

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:Hm. (0)

Anonymous Coward | more than 6 years ago | (#22492158)

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

scooped! (2, Funny)

troybob (1178331) | more than 6 years ago | (#22489676)

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! (1)

Profane MuthaFucka (574406) | more than 6 years ago | (#22491126)

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 (3, Interesting)

Yoweigh116 (185130) | more than 6 years ago | (#22489782)

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

Re:Surely You're Joking (1)

Protonk (599901) | more than 6 years ago | (#22489860)

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 (1)

Yoweigh116 (185130) | more than 6 years ago | (#22490182)

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

Bottom up easier in software (1)

esocid (946821) | more than 6 years ago | (#22489870)

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 (1)

Protonk (599901) | more than 6 years ago | (#22489984)

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)

FAILZORSA. (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22489990)

as WideOpecn, [goat.cx]

Chartered engineer status (4, Insightful)

Martin Spamer (244245) | more than 6 years ago | (#22490080)

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.

Your heart's in the right place, but... (2, Insightful)

Mariner28 (814350) | more than 6 years ago | (#22490540)

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:Chartered engineer status (0)

Anonymous Coward | more than 6 years ago | (#22490636)

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 (1)

dubl-u (51156) | more than 6 years ago | (#22492518)

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.

Fatal Defect (0)

Anonymous Coward | more than 6 years ago | (#22490144)

"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 (1)

CrazyJim1 (809850) | more than 6 years ago | (#22490164)

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 (0, Troll)

rholland356 (466635) | more than 6 years ago | (#22490774)

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 (1)

mapkinase (958129) | more than 6 years ago | (#22490310)

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

But that day is not today.

Re:yeah, right (1)

FrenchSilk (847696) | more than 6 years ago | (#22491814)

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 (1)

mapkinase (958129) | more than 6 years ago | (#22492244)

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

Software Engineers != Engineers (0)

Anonymous Coward | more than 6 years ago | (#22491394)

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 (1)

nguy (1207026) | more than 6 years ago | (#22491490)

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.

As a software quality professional... (5, Interesting)

gosand (234100) | more than 6 years ago | (#22491510)

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"

I didn't read TFA, but... (1)

cuantar (897695) | more than 6 years ago | (#22491564)

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

News sure travels slowly (1)

syousef (465911) | more than 6 years ago | (#22492252)

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.

Someone make sure NASA knows RAM is cheap now... (1)

TheQuantumShift (175338) | more than 6 years ago | (#22492478)

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 .. (1)

rs232 (849320) | more than 6 years ago | (#22492628)

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 ..
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?