Hacker News new | past | comments | ask | show | jobs | submit login
The Engineer’s Lament (newyorker.com)
248 points by nate on Apr 27, 2015 | hide | past | web | favorite | 144 comments



There's a very strongly held opinion in certain places in central Japan that the Toyota sudden acceleration issue has at no time ever actually been a true statement about engineering reality, and that it has been at all times an outright fabrication on the part of the American government to protect the domestic auto industry which is presently owned by the American government.

I would be more skeptical of this but for the reports coming out from the NHTS confirming "Yep, there is no there there" combined with the multi-billion dollar fines. It has the appearance of it just not mattering whether there were any faults in the vehicles.


There was a court case later that investigated the firmware of the drive by wire throttle control system software. Basically, design choices in the software implementation couldn't rule out the software as the source of unintended acceleration. All bets are off after stack overflow and continued execution.

Also the "brake override" wasn't a feature included at all which one could argue should have been part of the design.

In fact, software for car control systems should go through the same rigorous testing, documentation, control etc... (similar to what is required for FDA medical devices).

More: http://www.edn.com/design/automotive/4423428/Toyota-s-killer...


The court case showed that the throttle control programming was shoddy in various ways, but I don't think they demonstrated any observably buggy behavior, let alone any proof that software faults were behind any particular accident.

I think it's also quite possible that there never were any abnormal unintended accelerations, but the media debacle caused people to carefully investigate the cars, at which point they discovered that the programming was bad.


They actually demonstrated buggy behaviour, as well as the number of paths that could lead to that behaviour (very large).


It's hard to say whether it should or not. Something like that, sure. Perhaps not exactly the same thing.


> similar to what is required for FDA medical devices

Given how often we hear about gaping security holes in all sorts of medical devices, that doesn't seem like a particularly high standard.

Does anyone know whether Boeing and Airbus have higher standards for software quality?


Well, I've spent the last decade designing FDA cleared systems (class I and class III), and I can tell you that it is. That doesn't mean that mistakes aren't made, and it doesn't mean that you can't outright lie in documentation. There's no way the FDA could catch that short of replicating all of your V&V.

However, most of us aren't trying to cheat, and I can tell you that the amount of engineering rigor that goes into a medical device is leagues beyond what most software devs have ever been a part of. At my company we don't hire "developers"; we hire engineers who have programming in their toolbox.

Medical software screwups are high profile. You don't hear about every bug that the next "disruptive startup" lets into the wild.


I could see how that viewpoint seems valid from the perspective of a Japanese engineer. But those of us from America know that our government is far too incompetent to pull off something like this intentionally. The far more believable (and frankly, more American) response is that we created a bunch of hysteria and outrage over nothing. As this article shows, we have done this with our domestic car manufacturers as well (though I'm surprised nobody else commented that this was a Malcolm Gladwell article).

Furthermore, I'm not sure there's a whole lot of difference between domestic and foreign auto manufacturers at this point. The domestic auto companies still build parts overseas, and the foreign manufacturers still do manufacturing in the US. Also, large parts of domestically manufactured autos are either licensed or purchased directly from Japanese auto companies -- so a recall of a faulty part in a Japanese car would likely lead to recalls of American cars that use the same part. This was the case with the Honda airbag recall -- Chrysler used a lot of Honda-made airbags in its cars, and had to recall them as a result.


The Micheal Barr Group did a very high-profile autopsy on the code. The upshot is not good for Toyota.


Somewhere in my computers I have a PDF of Michael Barr's testimony. I read through it (< 300 pages) one evening with a friend. Both of us had worked in an embedded device company that dealt in life and death type devices, such as cars, traffic controls, etc. So we are familiar with the tools and rigor needed to design and develop safety critical systems. It is a matter of great professional interest to us to observe what transpires in legal cases relating to software quality.

Some of the key overall findings: The management was at fault, by picking people who were not experienced in developing real-time devices to lead software development (many software faults were those of inexperienced developers, and of developers inexperienced in real-time control). The lead developers were at fault, following extremely poor coding styles. The end code, of course, was badly done, as you might expect from management who didn't understand and leads inexperienced in the field.

Toyota, bluntly, messed up in breadth and depth when it came to software quality control. If you can find an unsafe coding practice listed on the web, Barr found it and detailed the precise ways it was unsafe. Huge interrupt service routines, complex logic in the wrong places, huge cyclomatic complexity.

It is understood in the world of safety and real-time software that certain designs of code are to be encouraged and others discouraged, based upon painful experience. It is not a handwavy "different strokes for different folks" field. The information from the Barr transcript can be used as a comprehensive manual of things to not do.


Is there a public version of their findings? Toyota hired Exponent to do an independent analysis of their electronic throttle and released that report to the public. It'd be interesting to compare Exponent's findings with the Barr Group. Exponent didn't find any plausible failure modes for the Toyota electronic throttle systems—their study looked very comprehensive, including a static code analysis and hardware-in-the-loop testing on the software side. They also did extensive hardware failure testing. It sounded like the Barr Group is claiming that the software was failing their quality tests, but it didn't sound like they were proposing a specific hardware or software failure that would lead to an uncommanded acceleration.


Right. No smoking gun.

There were multiple scenarios described in which such a failure was plausible. The story is nowhere as cut and dried as in the Therac or the Arianne cases.

Here are his Embedded Systems Conference slides: http://www.barrgroup.com/killer-apps/



Floor mats fit Gladwell's narrative much better than even mentioning software. His writing sounds like news, but it is not news, it is revisionist entertainment by omission. A half story, is half truth, is a lie.


It's an essay. An essay is whatever you want it to be.

Floor mats was a sort of strawman erected ( by someone other than Gladwell ) in the history of the subject.

He's illuminating the schism between how engineers think and how ... people ... who are not engineers .... think. Always a fun topic, IMO.


I am an engineer, and I don't think in the picture he paints. An essay is obviously opinion meant to sway opinion, that is not how Gladwell writes.

Both Toyota and GM acted maliciously in covering up flaws in the products they sold. For Gladwell to spin the folksy, aww shucks it is just the floor mats, you still have breaks is just as disingenuous as GM telling teenagers not to hang so much shit from their key chain.

http://www.safetyresearch.net/blog/articles/toyota-unintende...

> Jean Bookout and her friend and passenger Barbara Schwarz were exiting Interstate Highway 69 in Oklahoma, when she lost throttle control of her 2005 Camry. When the service brakes would not stop her speeding sedan, she threw the parking brake, leaving a 150-foot skid mark from right rear tire, and a 25-foot skid mark from the left. The Camry, however, continued speeding down the ramp and across the road at the bottom, crashing into an embankment. Schwarz died of her injuries; Bookout spent five months recovering from head and back injuries.


I am also a (software) engineer. I work on stuff that's much like the throttle controller on the Toyota without being directly automotive.

I don't think it's an opinion piece. It's just not journalism. People find Gladwell infuriating because he somewhat defies categorization and tries to take a very neutral, nonjudgemental tone. I said "essay" because that's as close as I could get.

I don't buy "acted maliciously". I don't agree that it was covered up. Malice implies intent; there was no intent. Indeed, that's the problem. There really isn't, to my knowledge, a fixed protocol for these things outside of whatever management or PR protocol you follow and then possibly the courts.

Toyota as an entity believed that it was acting responsibly.

From the article: "The engineers were right. A series of exhaustive investigations by federal regulators, with help from NASA engineers, established that the perception of an electronic failure was almost certainly illusory. The problem was caused either by the fact that some people put in poorly fitted, nonstandard floor mats or by the fact that drivers were pressing the accelerator thinking that it was the brake."

For one, Gladwell isn't the one saying it was the floor mats. The team of Federal regulators, with help from NASA engineers said that. Toyota took this seriously and launched an investigation.

Prior to Micheal Barr's analysis, I'd say it was formally undecided whether there was a software problem. Even then, the defects found were not a smoking gun.

This is new territory. The Barr Group is one of the first of its kind.


"Gladwell" is a synonym for "ignorant glibness". He doesn't understand anything he writes, and keeps right on going just as if he does. (Continued execution past a stack overflow.) Everything he writes should be assumed to be on the way to "not even wrong".


>It's an essay. An essay is whatever you want it to be.

I really can't say I like the trend of exploiting ambiguity to obscure the line between fact and fiction.


"and that it has been at all times an outright fabrication on the part of the American government to protect the domestic auto industry which is presently owned by the American government"

If there were a shred of truth to this the press and in particular news magazines like 60 minutes as well as WSJ and NYT would be all over this. There are people in this country who also believe that the government played a role in 9/11. As if a conspiracy such as that could actually be kept quiet given the number of players involved in pulling that off not to mention the absurdity of the idea to begin with.


> "unintended acceleration -> outright fabrication"

> If there were a shred of truth to this the press and in particular news magazines like 60 minutes as well as WSJ and NYT would be all over this

ROTFLMAO!!!

In the 80ies, it was 60 minutes who manufactured an "unintended acceleration" story, pretty much out of thin air. Well, some compressed air as well.

http://en.wikipedia.org/wiki/Sudden_unintended_acceleration#...

What they claimed was physically impossible, and never happened. More here:

http://www.manhattan-institute.org/html/cjm_18.htm

Anyway, here's the kicker: my dad, who was an executive at Volkswagen, received an anonymous letter in the 90ies, from people who claimed they had engineered this scare, and who offered their "services". Could have been a hoax, but considering how engineered the whole thing was and how effective, I am not so sure.

So I am ever so slightly skeptical when I hear of unintended acceleration stories, and I think your trust in 60 minutes and the rest of the media is, er, misplaced.


    >> If there were a shred of truth to this the press and in
    >> particular news magazines like 60 minutes as well as WSJ
    >> and NYT would be all over this

    > In the 80ies, it was 60 minutes who manufactured an
    > "unintended acceleration" story, pretty much out of thin air.
Unless you think that investigative journalism has a strong interest for Sudden Acceleration, the take-away here is that they have a strong interest in scandal and stories that sell newspapers/airtime/whatever. The US government conspiring to protect the domestic auto market is exactly the kind of scandal that sells newspapers.


...given the number of players involved...

While there are many good arguments against conspiracy theories, this is not one of them. Given how long it took for people like Snowden and Manning to come along, it seems compartmentalization, patriotism, and NDAs go a long way.

In the Toyota case, not many in-the-know would be required at all.


>the absurdity of the idea to begin with

A false flag operation initiated by America is an absurd idea? What about all the documented and public comings and goings of when America has done just that?

How in the hell is the notion of America creating an enemy to rally against absurd when there is proof of it occurring in the past?

Operation Northwoods - http://en.wikipedia.org/wiki/Operation_Northwoods

Project TP-Ajax - http://en.wikipedia.org/wiki/1953_Iranian_coup_d%27%C3%A9tat

Many people say the Gulf of Tonkin incident which initiated the Vietnam "conflict" was also one.

I'm astounded that you can make a statement like that when there is such black and white proof of such incidents occurring in the past. I'm not talking about 9/11, I'm just saying that it isn't out of the realm of possibility for a government to manufacture an enemy.

What I'm wondering is, are you just ignorant and you've never heard of these documented false flag operations? Or instead have you heard of these things and choose not to believe it?


You present evidence that the US has done such things in the past as evidence that it is not absurd to believe that 9/11 was a false flag operation.

But why is the idea that 9/11 was an inside job absurd? Is the only reason because people consider it absurd that the US would ever do such a thing? Or is it possible to believe that, yes, the US has done such things, but it is absurd to think that 9/11 was one of them?

I submit that it is possible to believe that the US has done such things, and also possible - even reasonable - to believe that it is still absurd to think that 9/11 was such an event.


Whether or not 9/11 was a priori suspicious is irrelevant. It's not September 12, 2001, it's nearly 15 years later and the investigations are long-finished and utterly conclusive.


    > A false flag operation initiated by America is an absurd 
    > idea? What about all the documented and public comings
    > and goings of when America has done just that?
I am confused by the links you follow up with. The first is a _rejected_ false-flag operation against American civilians, the second is CIA action overseas. The Gulf of Tonkin incident saw ... no American casualties.

And you use these as some kind of proof that the idea of the US government knowingly killing 3,000 of its own citizens, causing massive economic damage to the US, isn't absurd?!

    > What I'm wondering is, are you just ignorant and you've never
    > heard of these documented false flag operations? Or instead have
    > you heard of these things and choose not to believe it?
What, the first one, which never happened, or the second one which wasn't a false-flag incident against the American people, or the third one which involved no American casualties?


My 'Bait & Switch' light turned on half way through:

The author tries to move between mech-eng analysis (under controlled experimental conditions) - "what happens to this piece of metal in a 25 mph crash? how about 30?" vs. social-science analysis - "what happens to crashes when the state changes the excise tax on alcohol?"

It's not like there could be any confounding variables between states Oregon vs. Kentucky, the 1970's vs. the 1990's etc. It's all just data and engineers, right?


This article was written by Malcolm Gladwell. He frequently does that sort of thing in his books/essays.


The essay covered lots of things about the subject matter. Do you not think social scientists understand confounding variables, or do you assume they are idiots?


The Pinto wasn't an engineering failure ("it was a two-thousand-pound car on the road with four-thousand-pound cars. It got hit. It lit up. What do you expect?") but a Public Relations failure.

Jason Vines was the PR guy for Ford during the Firestone/Explorer disaster. And he had one guiding principle: Don't blame the customer. Which is what Toyota did with the unintended-acceleration problem.

http://www.amazon.com/What-Did-Jesus-Drive-Christianity-eboo...

"PR in a crisis cannot be cleaning up after the elephants in a parade. The PR team needs to have a seat at the table before, during, and after a crisis."


The engineering failure (as told to me by a college case study) was that there were exposed bolts directly in front of the gas tank, so a collision would almost always lead to a puncture, especially in a rear-end collision.

The fix was a 2-ounce, $2 piece of square plastic - it would cover the bolts, providing a flat face for the gas tank to impact the support beam. But Ford's leadership (Iacocca?) were too sold on the "sub-2000 pound car" and didn't allow this plastic piece, along with a ton of other features that were removed from the design.


The article suggests, though, that other compact cars had a similar bumper and fuel tank design, including sharp objects near the tank. The issue wasn't unique or exceptional. The one cherry-picked metric that came out of it was that the Pinto experienced puncture for rear end collisions at a marginally lower speed than other cars, and, after regulations were put in place to increase that minimum, fatality rates were not affected at all.

Any fatality effect is noise compared to the other causal factors in fatal accidents: highway design, speed, weight of the objects of collision, level of alcohol intoxication. And even factors within Ford's control trumped the Pinto gas tank design in importance. It's just that one particularly grisly and tragic death makes for some really bad PR.

Disclaimer: I've got no knowledge of the Pinto case besides hearsay and what's in this article.


Shouldn't you have put the disclaimer first? Gladwell has cherry picked reality to weave the narrative he wants.


I trust Gladwell and his research and interview access more than I trust your blanket, ad hominem dismissal of his work.


Unfortunately, this attitude is unjustified. Gladwell does research, but he'd be basically as reliable if he didn't bother. He doesn't use or understand the research he does.


> Disclaimer: I've got no knowledge of the Pinto case besides hearsay and what's in this article.

In that case, please don't post. Sharing what you know to be unreliable information makes everyone dumber.

That's not meant as a personal attack. Lots of folks do it, and you're at least good enough to admit it. But instead of admitting that you're making noise, why not just... not make noise?


Pretty much any vehicle with a rear-mounted gas tank is going to have problems with rear-end collisions. FCA (Fiat Chrysler Automobiles) is installing free trailer hitches on some Jeeps because they're vulnerable.

http://www-odi.nhtsa.dot.gov/owners/SearchResults?searchType...


Interesting - I remember an old debate that having a hitch is bad in a rear collision, because energy which would've been absorbed by a crumpling bumper instead ends up being transferred to the main chassis via the hitch.

Possibly the old argument is less valid due to unibody construction, but bumpers definitely exist for a reason


"Fix"?

From an engineering standpoint, the question is, "What proportion of accidents fall into the region between the force required to penetrate the tank with the bolts without the plastic guard, and the force required to penetrate the tank even with the guard?"


As I understand it, the bolts were pointing forward towards the fuel tank which caused the puncture and (the threads caused) the spark, but this was only in the Pinto wagon, a far less popular variant of the car. The hatchback most people think of as the Pinto did not have this design flaw (the bolts were perpendicular to the car instead of aiming forwards).

So, you had to rear-end a Pinto wagon (not hatchback) with a nearly empty tank so the bolts entered at the fume level for any chance of fire or explosion.


More recently there were controversies about Crown Vic cruiser fuel tanks rupturing in a collision - the reason was thought to be the tank hitting bolts used to mount additional police equipment

edit: http://en.wikipedia.org/wiki/Ford_Crown_Victoria#Fuel_tank


Yeah, you can contrast it with Tesla's handling of their battery fires where fires in crashes with no fire injuries (one at 100 mph from which the driver walked away) led to them fitting a new titanium underbody shield. Overkill from the engineering point of view but great PR.


This is really weird, I thought it was established that the Toyota acceleration WAS a phenomenon brought on by faulty microprocessor design:

http://www.edn.com/design/automotive/4423428/Toyota-s-killer...

Toyota's problem wasn't that they shouldn't have blamed the customer when it was the customer's fault, their problem was that they shouldn't have blamed the customer when it was Toyota's fault.


Toyota released an independent analysis of their electronic throttle system through their press website:

http://toyotanews.pressroom.toyota.com/article_display.cfm?a...

It's a fascinating report that includes a code review with PolySpace and hardware-in-the-loop testing. TL;dr, Exponent didn't find any hardware or software design defects that could cause "uncommanded acceleration". Barr's analysis in the linked article sounds like he found problems that should have been caught by their coding standards and design reviews, but it doesn't sound like he found or could suggest a specific event sequence that could lead to an UA.


If Toyota had anything to do with that analysis then it wasn't independent.

My recollection of the Barr analysis is that a particular failure case was in fact described which occurs during certain conditions of memory exhaustion:

http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyo...

"the team led by Barr Group found what the NASA team sought but couldn’t find: 'a systematic software malfunction in the Main CPU that opens the throttle without operator action and continues to properly control fuel injection and ignition' that is not reliably detected by any fail-safe."


I don't see why an independent analysis commissioned by Toyota would be any more or less credible because Toyota paid for it than an analysis by an expert witness paid for by a plaintiff in a civil suit. I should think they deserve equal scrutiny.

Reading the transcript of the court proceedings, it sounded like Barr Group were able to induce a fault that could lead to an unintended acceleration, but the evidence that this fault actually happened was circumstantial.

Also, I don't find the jury's decision against Toyota to be relevant, given that there are so many other elements that figure into the calculus of a jury decision. I can't fault Barr Group for trumpeting that they were a key expert witness in a successful trial of this magnitude—it's phenomenal advertising—but I don't see how it follows that their failure proposal is actually what happened (nor do I think that the Barr Group would say with certainty that it did happen).


How would it be anything other than circumstantial that it "actually happened"? Those cars crashed and people died. You could make the same case about any bug; "I duplicated the behavior, but that doesn't mean it actually happened in the original bug report". That kind of developer comment would raise eyebrows.

Toyota's original defense was that it was user error because unintended acceleration couldn't happen; they blamed it entirely on driver error. They were making a "forall" argument, and all Barr had to do was show an "exists". He did. Toyota was completely wrong.


> How would it be anything other than circumstantial that it "actually happened"?

Because the fault could trigger a DTC. Barr's argument was that the right kind of bit flip event could cause a fault and it would not be logged as a DTC. The beauty of Barr's theory is that it leaves no evidence if it was the cause of a real-world accident. The plaintiffs successfully argued that Barr's theory was the most plausible explanation for the accident, not that it was the cause.

> You could make the same case about any bug; "I duplicated the behavior, but that doesn't mean it actually happened in the original bug report".

I think this analogy is misplaced, here, there would be no bug report other than "the system crashed" (no pun intended). In which case, your statement would be accurate and proper.

> Toyota's original defense was that it was user error because unintended acceleration couldn't happen; they blamed it entirely on driver error. They were making a "forall" argument, and all Barr had to do was show an "exists". He did. Toyota was completely wrong.

Toyota's defense was that user error was the most likely explanation; the plaintiff via Barr argued that a software defect was the most likely. The plaintiff prevailed, but that has no bearing on what actually (or likely) happened.


As far as I followed the story, the BARR group only found it was possible, but couldn't replicate the condition.

I would also be careful in stating who is independant. Mr Barr also have an incentive to claim the code is terrible since he sells static code analysis software and embedded programming bootcamps. That's great advertising for his business.

Would your code stand up to the rigours of a Barr analysis?

Would any automotive code from any other manufacturer stand up to Barr analysis?

Would any other industry stand up to Barr analysis?

We don't know the answers to these questions...It is for instance well known that if your code is squeeky clean according to one static analysis package, just running another static analyser will raise a host of other warnings.


This is a great example of the difference in mindset between software developers in modern companies doing non-embedded work, and folks in more traditional mechanical or chemical engineering roles. Very, very different calculus.

EDIT:

Interestingly, we've got potentially much better instrumentation and analytics on our side...note how long it took to get those accidents reported, and then think how long it takes to do that kind of analysis on your production systems of what users have had problems when.


There's a crucial decision the Toyota engineers made, as described by the article, which was that if the stuck accelerator was not preventing the driver from using the brake and slowing the vehicle, then the stuck accelerator is acceptable (we're talking about a small number of reports) and no fix should be made.

It's not easy to understand why they would make that decision. I imagine a stuck pedal is likely to cause confusion in a driver. It would take some time before a driver will process what is happening, and realize that the accel pedal is indeed stuck. It seems like surely it would cause accidents.

Furthermore, it's not a tough problem to design a pedal that moves back and forth in high humidity or high temperatures that a car interior is going to see. And it's not expensive.

But we're seeing this fault in isolation. The engineers are likely thinking, "Suppose we fix this problem. That's fixed, and it cost $2 per car. Now, what are the 1000 other items that could fail and cause a similar moment of confusion, of the kind that might contribute, or seem to contribute to an accident? What will it cost to fix all of them, because fixing just one doesn't solve the problem."


But they did fix the problem. They just didn't recall the existing cars. According to the article, they fixed the pedal for subsequent models of the car.

> Furthermore, it's not a tough problem to design a pedal that moves back and forth in high humidity or high temperatures that a car interior is going to see. And it's not expensive.

According to the article, the problem was that the material of the pedal was unexpectedly degrading in that environment, causing it to become stuck. This isn't a matter of it being expensive to produce a better pedal, it's simply a matter of an unforeseen interaction (which would argue that it is in fact hard to design a pedal that works flawlessly in that environment). And so they fixed it on subsequent models. But fixing it on all the existing cars out there would amount to an expensive recall that seemed to be rather unnecessary.

> I imagine a stuck pedal is likely to cause confusion in a driver. It would take some time before a driver will process what is happening, and realize that the accel pedal is indeed stuck. It seems like surely it would cause accidents.

According to the article, at the time when the issue first cropped up, there were no known cases of an accident caused by the stuck accelerator (note: I don't know if any happened later). Furthermore, the natural reaction to "my car is unexpectedly accelerating" is to slam on the brakes. I could easily see someone panicking, but a panicking person doesn't forget that the brake pedal exists, especially since all drivers have been conditioned to understand that pressing the brake pedal is how you stop the car.

Based on this, their response seems pretty straightforward. Yes, there's a relatively rare issue with a stuck accelerator, but (at least at the time) there's no known cases of this leading to an accident, and the natural response by a driver upon encountering the problem, which is to hit the brakes, is sufficient to neutralize the issue. Therefore, no expensive recall is necessary.

That said, they obviously had a PR problem. And it was magnified by the media's propensity to hype up situations like this, turning it into a newsworthy story (because that gets more viewers). It seems the vast majority of incidences of unexpected acceleration were not even caused by the stuck accelerator, they were either caused by poorly-fitting third-party floor mats, or by people inadvertently pressing the accelerator when they meant to press the brake, both of which are issues that are not unique to Toyota cars (in point of fact, to the best of my knowledge, every incidence of someone unable to stop the car by pressing the brake pedal was in fact pedal confusion, where they were pressing the accelerator thinking it was the brake, and therefore not caused by this defect at all).

Ultimately, I think Toyota had the right engineering response, they just needed to fix their PR response. Don't let the engineers dictate communication to the customers. Understand that reality and public perception are often at odds with each other, and that public perception is just as important as reality. That's not to say that they should have issued a recall, because they shouldn't (if anything, that would have reinforced public perception that the cars were dangerous). But they should have realized that they needed to communicate with the public in a different fashion.


This is the whole idea behind the article:

>“The Toyota guy explained this to the panel,” Martin went on. “He said, ‘Here’s our process.’ So I said to him, ‘What do you imagine the people are thinking? They’re shaking like a leaf at the side of the road and after that whole experience they are told, “The car’s fine. Chill out. Don’t make mistakes anymore.” Of course they are not going to be happy. These people are scared. What if instead you sent people out who could be genuinely empathetic? What if you said, “We’re sorry this happened. What we’re worried about is your comfort and your confidence and your safety. We’re going to check your car. If you’re just scared of this car, we’ll take it back and give you another, because your feeling of confidence matters more than anything else.” ’ It was a sort of revelation. He wasn’t a dumb guy. He was an engineer. He only thought about doing things from an engineer’s standpoint. They changed what those teams did, and they started getting love letters from people.”


Thats a double edged sword. The thing is, it was not their job to make people feel better, it was their job to evaluate the situation. There is a good and a bad side of that trade off...


Yep. The exceptional error gets the grease, even though its a one-in-a-million event. Invoke the feels, and the majority of people lose their shit. Give them data, and their brains turn off.

BUT THINK ABOUT THE CHILDREN!


"BUT EMOTE ABOUT THE CHILDREN!"

FTFY. =)


An interesting paper. "The Myth of the Ford Pinto Case":

http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pint...


PDF warning


This is a brilliant quote:

"Surely this is why Jimmy Carter remains the most puzzling American President in recent times. We have too often insisted on trying to understand him using the default modes of identity politics: as a white, Southern born-again Christian. But Carter was by profession and training an engineer—a disciple of the greatest and most influential engineer in the history of the U.S. Navy, Admiral Hyman Rickover. Rickover, Carter once said, had more influence on him than anyone except his parents. In his literalness, his relentless candor, his practicality, Carter was the Toyota engineer by the side of the road doggedly lecturing us on how to drive the car. Carter’s true nature is puzzling only if we remain rooted in the fantasy that the world we inherit somehow matters more than the world that we chose for ourselves—and that surrounds us, from nine to five, every working day of our adult lives."


I thought it was abrupt and reaching. It felt like the author has this tidbit about Carter laying around that he'd been holding on to, but wasn't sure where to use it. He thought it could maybe fit here, but it just was jarring. Not to mention that Carter isn't quite recent enough for me to really have any context about the comparison (what policy decisions set Carter apart?). Finally, the injection of race and religion in this otherwise unrelated article was just out of the blue.


Yeah, the Carter bit made no sense. I remember Carter, and a lot of his bad decisions were very much NOT the result of "engineer thinking". One that comes immediately to mind is his executive order outlawing breeder reactors, which has basically saddled us with being unable to cleanly reprocess reactor waste back into usable fuel. Never mind the fact that only a very specific type of breeder reactor produces weapons-grade plutonium, and never mind that as a nuclear enginner he SHOULD have known this, he still banned them in a bizarre attempt to ingratiate himself with the 70's "disarmament/anti nuke" movement that never seemed to fully grasp the distinction between nuclear WEAPONS and nuclear POWER.


The "injection of race and religion" was not that at all, rather an observation of the usual "identity" attached to him.

I agree with the idea that many or most readers won't have a working knowledge of Carter's policy--I certainly fall into that group.


The most ridiculous fix to a serious car problem, to me, was that with the GM Cobalt et al. cars: http://engineeringethicsblog.blogspot.com/2014/06/the-switch...

Anyone can see that the 'fix' was half-baked. This is a weird analogy, but it popped into my mind to fit the unbelievable situation:

It's like designing a traveling laptop-cooling station where the laptop sits on a strainer, which is almost touching a pool of water. The fix was to increase the gap between the strainer and the water by 1cm. Surprisingly, laptops would still get wet after the fix.


What's more bizarre is that turning the key should completely devastate the car. Faulty switch or not, that sounds pointlessly hazardous. I'm hoping there's a good reason for this, but it sounds really terrible.

Do "keyless" cars immediately shut off when you press the stop button while driving?


There is an entertaining video of Milton Friedman discussing the same issues with an audience member:

https://www.youtube.com/watch?v=jltnBOrCB7I


Very interesting. I was amazed that the video seemed to be uploaded with the intent of showing what a disgusting human being Friedman is, when in fact his points (in this particular discussion) are quite uncontroversial.


Yeah though his point that if consumers want to pay $13 less for a Pinto without the plastic block they should be free to do so is impractical from the point of view of consumers being able to analyse that stuff. (4m55)


Yeah. You can also find the same clip uploaded with the opposite intent.


I find it strange that the shadow, or wake, of the 1960s Ralph Nader case ( http://en.wikipedia.org/wiki/Unsafe_at_Any_Speed ) is not mentioned.

Rather large elephant.


> Also in part because of that, the F.A.A. has close to fifty thousand

> employees—an order of magnitude more employees than we do. We have six hundred.

Am I missing something? 50,000 vs 600 is two orders of magnitude difference.

Perhaps the person quoted was speaking colloquially, but I would argue such a quotation should have a [sic] in it.


One thing you're missing is that 25,000 of the FAA employees are Air Traffic Controllers. There is no equivalent function that NHTSA does that would require that many employees.

This whole comparison grated on me. Either the NHTSA guy is an idiot or Gladwell is an idiot or both, likely both. Or they're deliberately prevaricating and hoping that most people won't notice. I can't stand sloppy "factoids" like that. Context is essential.


In physical engineering two principle tools are used to control projects : specifications and tolerances.

I software we have a kind of specification (generally dimensioned and rather fuzzy) but no concept of tolerance.

But also software quality seems to me to be more fundamentally about perception than anything else.


The problem with software is that the software is the specification. Any sufficiently detailed software spec will need to be written in a formal language that might as well be code.


I know that's received wisdom in some parts, but is it actually true? Is it true for other engineering disciplines? Is it true for hardware design? If not, what makes software special?

I think it only seems true because of the amount of money people are willing to invest in software development, relative to other ventures.


It's just a property of the artifact you're building. You're designing a process instead of a product. The artifact you produce is a description of that process--code.

The closet thing I can think of is anyone who works on processes instead of products. If you look at disciplines that design processes, the larger the scope of the process, the less exact the methods to design them (mainly because the number of variables grows too large).

At one end, industrial engineers who design assembly lines have very rigorous design methodologies backed by math and empirical data. At the other extreme you have politicians designing the process of running a country, and their methodologies are almost never based on math or empirical evidence.

One way I've heard it described is kind of midway between an industrial engineer and a politician--When designing a large scale software system, you should be like an urban planner. You decide what kind of zoning you need--residential over here, commercial over there. Then you build the roads and other infrastructure that connects the various districts.


I agree with your analogies, but I think that there are at least a few intermediate levels between high-level process description and code that benefit from some sort of spec. Good specs fill the gaps between the zoning and the pavement.


> If not, what makes software special?

There is no ASCII representation of a bridge which is actually a bridge. Other engineering disciplines are in the business of producing matter with certain properties; the description of the properties is fundamentally distinct from the matter itself.

There is an ASCII representation of every piece of software which is actually that software: its source code.

This would also explain why "code as spec" goes hand in hand with modern, expressive languages: a sufficiently large C program is not human-readable as a description of its own behavior. If you want to create the program you intend to create, it is necessary to write a specification at a higher level of abstraction, then hand-translate that into C, and attempt to keep the two in sync.

Whereas one can read/write business logic in Ruby, Python, or whatever about as well as they can read/write a description of the same logic in English.


A sufficiently large program in [any language] is not readable as a description of its own behavior. I think it's easy to fall into the trap of thinking this is not true for expressive languages like Ruby or Python, because there are precious few projects of sufficient complexity written in those languages.

If you think I'm wrong, please show me the Ruby equivalent of an os kernel or Photoshop, and I'll reevaluate my thinking.

More importantly, every program can be seen as, at some level, a description of its own behavior. But none contain a description of the system's intent.

That's what specs are for.


Tolerances do come into play in safety and security engineering, and also when designing for reliability.

* What are the likely failure modes for this subsystem?

* What are the consequences if it fails?

* How much should we invest in analysis and testing of this subsystem or aspect of the software?

* When we find out about a severe issue internally (not known to the public), do we issue an "out of cycle" patch immediately, or do we wait for the next release? Do we tell customers about it?

I know there's some moral hazard in our industry, because it is rare to see software companies advising users of security problems that weren't reported by a third party.

The usual case (in closed-source) is that security issues discovered internally are quietly fixed without notifying the customer.


He argues for overturning the deeply held—and, in his view, irrational—proscription against two-foot driving. If drivers used one foot for the accelerator and the other foot for the brake, he says, they would be far less likely to mistake one pedal for the other.

...? I've always driven that way, except when I was practicing on a stick shift (which I did not like, because it had more pedals than I have feet).

Do people seriously not like doing this for some reason?


Historically people who drive with one foot on each pedal go through brake pads faster as a function of overlap between the application of throttle and brake.

When I was taking Drivers Education (way back when) my teach asserted that from a neurological perspective it was faster for the brain to use one foot than two, because using two introduced an additional step in the process of deciding which part of the body to active. His claim (and I don't recall him providing direct evidence of this) that having go/stop be a choice of two movements of a single limb, allowed you to react faster than picking which of two limbs to activate for the desired behavior.


Historically people drove stick. And clutches were hard. Like seriously hard. I remember driving a tractor when I was 10 and I had to use my whole body weight to move the clutch.

So people's left foots were not sensitive enough for the break. Whereas the right foot was trained on the soft accelerator.

As a stick shift driver, it took me years to learn left-foot braking without stomping on the break and coming to an immediate full stop. But left-foot braking comes in very very handy on snow and gravel. It's also a lot of fun.

PS: modern clutches are soft, but you still usually either depress it fully or leave it alone, which means your left foot isn't too well trained in applying varied degrees of pressure


I would think that this would be true as you are learning, but once you have been performing the two-foot motion for several thousand miles I would think the action would be so ingrained in your muscle-memory as to remove entirely that cognitive decision. At some point you stop thinking about which foot and just automatically know brake=left foot.


As a lifelong manual card driver with a left-foot clutch, it takes about, oh, ten seconds of sitting in a go-kart with left foot brake and right foot accelerator to get used to it and adapt. There seems to be no real difficulty in switching which leg does what.


Having learned and then driven stick for eight years afterwards, I still occasionally roll through stop lights because I am stomping on the non-existent clutch pedal of my automatic truck before I brake...

Good luck finding a stick shift if you don't custom order it these days, btw


Depends what you're buying:

http://www.ford.com/cars/mustang/models/


I was explicitly taught not to do this, both in Driver's Ed and by my father. The explanation I was given was that it's bad for the car, since you'll tend to apply light brake pressure while accelerating which wears out the drive train and the brakes. Also it turns on your brake lights, potentially confusing other drivers.


Newer 3 pedal VWs apparently don't allow you to use the brake and the accelerator at the same time, which annoys people who heel and toe (left foot using clutch, heel of right foot pressing the brake and right toe blipping the gas to rev match on a downshift).

Edit: after doing some reading it seems this only happens when you aren't using the clutch, which means it makes left foot braking impossible.


A few of my relatives do this and it's always immediately obvious when you drive with them. The ride is substantially more jerky (although they claim there isn't a difference) and the break light is on half the time we're on the road.


Only half the time?

Yes, the author and proponent of this method of driving neglect this point entirely, and that it is clearly more dangerous (for the following drivers) to drive with "broken" brake lights.

But perhaps he believes that this habit could be broken as well?


It doesn't matter that there are more pedals than you have feet, since you never need to use more than two of them at a time. Your computer keyboard has more keys than you have fingers, but in general that doesn't cause problems.


There is at least one situation (heal-and-toe dance while downshifting and braking) where you are in fact using all three pedals - not exactly at the same time, but close enough that you want to use heel and toe for accelerator and brake, because you don't have time to move your leg back and forth.


I can't envision that scenario (I would just not downshift if it required the gas, which in my experience, it doesn't).

I do know of a 3-pedal scenario, though--on an uphill stop, maybe a traffic light, when another car gets close enough to you that you cannot afford to roll backwards. If you haven't planned for the situation (by using the clutch to maintain position rather than the brake), you'll need to continue braking while you start the car moving forward, to prevent rolling back.


Actually, using the clutch to maintain position is bad too. It heats the clutch up, which changes it's operation properties and very seriously reduces it's operating life.

I was taught to approach target position on hill, disengage gear train, use brake to hold car. Then, quickly switch from brake to clutch while applying gas... That's tough too.

So I always used the hand brake, leaving my two feet ready to use clutch and gas. In that case, it's optimal. Apply clutch and gas, until car begins to want to move, release hand brake and continue.

I won't own a manual car lacking a hand brake for this cuse case alone.

Now, with skill, it's entirely possible to do this with just the three pedals. One needs to release the brake, and while moving the foot to the clutch, engage gas and very rapidly find the engage point of the clutch and then continue to get the car into motion from there.

Roll back on this is perhaps an inch or maybe two done well.

I can do it, and was made to practice this, but I don't like doing it at all as it requires one to really execute a few things quickly with good precision.


I gas and brake with the same foot (it sounds like you clutch and brake with the left).

I can do the hill thing without rolling back in a car I'm familiar with, if the hill is not overly steep. Basically I hit the engage point while still depressing the brake. If the hill is too steep, you can stall doing this.

Anyway, I realize it's bad to use your clutch that way, but it seems better than rolling into a car, in most cases.


Total risk skill dynamic.

I can release the brake and engage clutch quickly enough in a car I have driven to avoid a significant roll. There is always the hand brake too.

I never replace clutches either. In most cases replacement is not too expensive, so whatever works right?


It may be that I just have never had to down-shift in traffic where I couldn't drop all the way to first and come back up. But usually I'm shifting up because I'm going too slow, or dropping a gear because of the jackass in front not going the speed limit.


Often people end up resting their feet on the brake pedal just enough to turn on the brake lights which makes them useless as indicators to the people behind you.


In a panic scenario, it's likely BOTH pedals will be engaged, and that's not likely to be the optimal response.

I was explicitly taught not to do this as well, and I've seen it go bad in action too. In many cars, slamming both pedals down hard results in the car continuing to move, when it's usually desirable for the car to quit moving more than it is for the car to speed up.


Yes, because I have the habit of applying clutch pressure with my left foot--it makes for a great panic stop.


What i find most worrying about this article is the change in thinking once one has been with a organization for some time.

That in turn brings to mind the Challanger debacle, and the claim that it happened because the CEO of the company making the o-rings shifted his thinking from engineer to management during the go/no-go conference call. And subsequently changed his stance from a initial no-go (engineering) to a go (management)...


Absolutely fascinating and very insightful into the differences in perspective between engineering and other disciplines.


Toyota's problem was real, and the author hot it wrong: http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyo...


Gladwell doesn't say there was no problem. He says "[in the Pinto case] two dozen of their occupants were killed by fires from rear collisions. The number of deaths linked to the Toyota sudden-acceleration complaints was about the same." And then points out that number is small compared the number of lives that could be saved many other ways.


> Only the engineer tries to solve the problem.

Wrong! The Ophthalmologist, and Priest were also trying to solve the problem. That joke, which is old because it is so good, has a deeper message.


In fact, the three of them don't even agree on what the problem is.

Priest: We're frustrated.

Ophthalmologist: The firefighters are blind.

Engineer: The golf course is running inefficiently.


Which is exactly why the first rule of good problem solving is to re-state the problem. :)


Well, I would say that the Doctor offered to explore a solution to the firefighters issue, the engineer offered a work-around that would make his life easier at the expense of others.

"Have you turned it off and on again?"


The point is that it wouldn't really be at the expense of others - it doesn't matter if it's dark if the players are blind.

(Yes, restricting them to only playing at night may cause scheduling conflicts but it's a joke and of course omits such details.)


Scheduling conflicts? Requiring others to flop their lives by 180 degrees so you can play a round of golf is a scheduling conflict?

And the joke here is being used to illustrate a point (that the engineer thought of a solution when no one else did), I'm using it to point out that the engineer offered no solution while keeping to the general disregard for others in their simple work-arounds.

Just hold it differently.


He could have also just offered to play at a different golf course. That would be inconvenient. But maybe the golf course isn't open at night? Why should it be? Or maybe the firefighters don't have the time to do it at night?

It's an idea, but it's not an example of "solving the problem." It solves his problem, but probably creates problems for others.


Every Engineer's Solemn Duty

http://www.warplife.com/ethics/duty.html


I think this is like a lot of things; the theory is sound, but the hard part is figuring out when it applies. It can be misapplied at both the low and high ends, and there's a vast murky middle.


"vast murky middle".

I eagerly enrolled in Ethics my first term at UCSC, in hopes of learning The Answers To All Of Life's Great Questions.

Instead I learned how to make tedious, hair-splitting arguments. While I readily agreed that the philosophy prof who taught the class had valid arguments, they were so complex that I didn't think they would do anyone any real good.

The one thing I took away from the class was the concept of "The Minimally-Sufficient Samaritan". A Good Samaritan will risk their life for that of another; a bad Samaritan won't. A Minimally-Sufficient Samaritan will only do enough that they are regarded as ethical.


I took a class called "Contemporary Moral Problems" from a professor who suspiciously resembled Captain Kangaroo. In it, I found my favorite statement from philosophy:

"I find it plausible to believe that I have a moral duty not to wantonly slaughter my neighbors."

(How many wishy-washy terms can you find in it?)

The Minimally-Sufficient Samaritan is entering my lexicon. Thanks!


It's a little annoying to see the author retell the story of Toyota's prius acceleration problem as if it were a defect with the peddle.

We know now that it was a problem with spaghetti code firmware, lack of testing, & poor system design.

See here http://www.edn.com/design/automotive/4423428/Toyota-s-killer...


I'm actually shocked at this article's underlying message, which seems to be implying that since engineering perfection is unobtainable, good enough within the given time and material constraints is acceptable and these recall issues were more of a PR problem.

Ford and Toyota are companies that generates billions of dollars in profit. Think about that. It in no way realistically ran into any constraints that were not arbitrary. You can hire more engineers. You can hire better engineers. This is not a question of a scrappy start up needing to release something or go bust.

I'm not anti-capitalism. I understand companies run into actual, real constraints that prevent perfection. But do we care that the defects and safety issues are dwarfed by poor driving? How are these self imposed 'constraints' on engineering anything but maximizing shareholder value at the expense of public safety?


> which seems to be implying that since engineering perfection is unobtainable

It is unobtainable. Full stop. The end.

No amount of money thrown at a problem can absolutely, positively, 100% guarantee safety. Even if you had a car that cost $1b it still wouldn't be perfect. It might have a perfect safety record but that's because there would only be 500 drivers on the road worldwide and at that kind of a very, very sparse distribution cars might only pass one another a few times per day. It might take years or decades for enough car-to-car interactions to take place to find the remaining weak spots in the billion dollar car to ensure that it didn't accidentally kill someone.

But in the mean time you'd make millions if not billions of people poorer for not having the ability to drive cars which exist in the realm of affordability. Nearly everything is always about time and material (and monetary) constraints. If it wasn't we'd all own skyscrapers and have private yachts and vacation all the time and etc, etc, etc.

> Ford and Toyota are companies that generates billions of dollars in profit.

And? Ford has $53b of "property, plant and equipment" and on that $53b it made a profit of $5b in 2012, $7b in 2013 and $3b in 2014. That averages out to $5b or a little under 10% annualized yield. Since automobile design and manufacturing is a little more complicated than real estate, so it shouldn't be surprising that the yield is higher.

http://finance.yahoo.com/q/bs?s=F+Balance+Sheet&annual

http://finance.yahoo.com/q/is?s=F+Income+Statement&annual


I was trying to explain this concept to our sales rep today. He seems to think that releasing a product means that it is 100% finished and there will never be any problems with it ever. Reality is that we are always one bizarre untested configuration away from having an issue on a new install.

The terms "Beta" and "Gold" have this magical aspect for some classes of people, which I just can't get my head around, seeing the trunk code change every day.


That's why ALARP is such a widely used methodology.

Unless you're in the bands "unacceptable risk" or "broadly acceptable risk", economical considerations are valid.


That's a cop out argument.

Gas pedals and ignition switches are things that have existed for decades. Why are they screwing around with materials that don't perform well for a part as universal as a gas or brake pedal? Why not leave the damn thing alone?


In part because throttle and ignition control are increasingly eschewing mechanical linkages in favor of electronics. IIRC, the Camry in question had an electronic throttle, and the pedal part that experienced accelerated wear was an acetal bearing surface that was supposed to mimic the feel of a traditional throttle control. I don't know the details of this case, but acetal isn't uncommon for bearing applications.

As to why move to electronic throttle, it's mostly due to regulatory compliance.


> In part because throttle and ignition control are increasingly eschewing mechanical linkages in favor of electronics.

I would go further than this. I would guess that at least 50% of the cars on the road today have electronic-only throttles and that fully 99% of cars sold in the last year have had electronic-only throttles.

Drive-by-wire is basically the standard these days, even on very inexpensive cars. Emissions standards have basically forced it.


So you have a safety critical component that was redesigned (with a floor mat recall) in the last decade, and modified after a series of incidents.

Sounds like an engineering failure to me.


Parts are changed all the time over the production run of a car. How does that constitutes an "engineering failure"?


The materials degrade and fail, and the design of the physical environment around the pedals makes it easy for OEM or aftermarket floor mats to create fatal conditions.

The physical properties of pedals are well-known. Material failure of a pedal in the 21st century is a complete fuckup. Floor mats are known quantities as well. Perhaps design elements beyond weakly anchored plastic hooks embedded in the rug would make it more difficult for a sliding piece of rug or rubber to kill the occupants of the car.

Well engineered products should work in the environment that they operate in. These cars didn't perform in a variety of typical conditions, putting human life at risk. The "obvious" workarounds presented by the engineers aren't things that drivers are trained to do and aren't obvious to drivers in emergency situations.

That pretty much defines failure in my mind.


> aftermarket floor mats

How is it reasonable to hold a car manufacturer responsible for what could happen with aftermarket parts, unless those parts are designed to be an exact duplicate of an OEM part?

> Well engineered products should work in the environment that they operate in.

Completely agree. Toyota has produced a lot of cars, and only a minuscule subset seems to have actually been affected.

> These cars didn't perform in a variety of typical conditions, putting human life at risk.

Human life is at risk whenever a person is driving in a car, regardless of manufacturer. I think the proper question is do the Toyota designed cars present an unacceptable risk?

> The "obvious" workarounds presented by the engineers aren't things that drivers are trained to do and aren't obvious to drivers in emergency situations.

Stomping on the brakes seems like a reasonable response to an unintended acceleration event for an untrained person, and was experimentally shown in Toyotas to be sufficient to stop the car with an open throttle in a reasonable distance. If Toyota has a proper risk management plan in place (and I don't know of any evidence that they lack one), it would incorporate risk mitigation for an unintended acceleration. How an untrained driver would react, or a driver who didn't read the instruction manual, would be considered in the risk management plan.

As to driver training, I personally was taught that applying full brakes, handbrake, placing the transmission into neutral, and killing the engine are all options, in addition to the downsides of all of these. I am certain that many drivers don't know this, but to say that all drivers aren't trained on remedies is not wholly accurate.

As I see it, a true engineering failure is if there isn't a corrective process in place to replace affected parts and if there isn't a process to incorporate design process changes to prevent these problems from occurring in the future; clearly, there is a quality system in place. If Toyota produced new cars that had floor mats or pedals that had the previous problems that would be a clear engineering failure. What actually happened was that the cars were produced under the constraints of a realistic budget and acceptable defect rate.


Just out of curiosity, what would be the perfect car? I mean, perfect while still being obtainable within the laws of physics as we understand them.

Even if money was no object, you can't build a car that is 100% optimal in every aspect. Every change you make causes a tradeoff elsewhere. Adding armor helps in some collisions, but it just got heavier and slower to stop so it's less safe in other situations. Move the gas tank up higher to avoid that rear collision problem, and now the center of gravity is higher so it won't corner as well and might roll over more easily.


A 1980s style pickup with the bodywork replaced with aluminum or fiberglass would probably last forever. I've known many 80s Ford or Toyoras to be very fixable after the original engines quit. Ususually, at least in the north-east, the snow and salt rots out vehicles bef0re they really get to junk level


On the west coast, those cars run forever.

My old '89 Corolla has something like 350K miles on it. Runs great, drives great, 40 MPG, and it's got a throttle body fuel delivery too. Insane!

It's possible for a person to almost completely disassemble, understand and reassemble and modify a car from that era. People do it all the time.


Or a '90s 4-banger Nissan Hardbody with a manual transmission. My father has one and there's a list of people waiting to buy it off him if he's ever willing to sell. Those things are great.


Profit per car for car manufacturers is often under $1000 per car. That's not even close to enough money for perfection.


Are profit and perfection correlated? Seems unlikely.


Inversely correlated. Perfection costs.


Apple is an obvious counterexample (high perfection and high profit). Sure, perfection costs more, but does that directly affect profit?


Constraints often involve tradeoffs as opposed to money. I don't know much about cars, but I am an active rock climber. Climbing is probably unique in that these sorts of engineering tradeoffs concerning life and death are part of the sport.

Perhaps the best example is found in the gear used and its placement. Cords, slings, and webbing (short pieces of tubing or cord used to build anchors or fix gear) were typically made of nylon back in the day. Military grade plastics [1] entered the climbing scene by the 90s. These plastics are both much stronger and lighter than nylon. For that matter, they are actually stronger than steel.

In practice, they are so much stronger that they don't stretch at all. The obvious effect is that falls exert a much larger force on both the climber and the gear. Gear rarely fails, but it does punch holes through rock ripping its way out. The other effect is that dyneema effectively sheds redundancy from anchors. A bit of background is in order.

Anchors are typically attached to the rock via more than one piece of pro(tection). A cordelette (short cord 20 feet in length) is attached to all the pro and tied into a knot (the master point). Depending on the position of the pro, the legs of the cordelette can be doubled (or more) to make a stronger anchor. A cordelette made of nylon stretches enough that the total weight it holds is nearly additive of the number of independent legs. Dyneema, on the other hand, will break at the tensile strength of a single leg no matter what. In the concrete, 5mm dyneema may hold up to 5000 pounds, while a 7mm nylon cord will hold 2800 pounds or so per leg. In most cases, an anchor of nylon is both stronger and more forgiving because it stretches more.

If we didn't have enough to consider already, space age plastics rapidly loose strength under very moderate weighting cycles and degrade quickly in the sun.

Which plastic is better? Or better yet, which one would you use? Nylon means falls are typically safer, but you are more likely to take a fall because you will fatigue more quickly. Of course, if you can hit the deck (eg, a ledge below you) or can't double up the cord, you'd want to use dyneema. However, I certainly wouldn't want to take multiple falls in succession on dyneema.

| Think about that. It in no way realistically ran into any constraints that were not arbitrary.

More engineers, better engineers, and more money can't solve this problem. You have to pick your cords ahead of time and live (or not) with the decision.

[1] http://en.wikipedia.org/wiki/Ultra-high-molecular-weight_pol...


This is an excellent analogy.


This seems to be analogous to the Iron Triangle rule: Fast, Cheap or Good, pick two.

You could optimize for perfect engineering, maybe (real-life throws in lots of random, exceptional events, though), but its going to cost you up the wazoo and take forever to finish.


Agreed, but with engineering though it's never that binary.

Each dimension is a continuum. You have to end up picking some point on each dimension that is either good enough or the best you can do with your budget also considering that you have to balance this across many many individual decisions. Prioritising these decisions against each other is also done with incomplete information.

As mentioned in the article engineered items are not in a binary state of faulty or not faulty - it's more 'analog' with physical engineering. Rather they have varying degrees of resilience to different often competing failure modes.

And changing requirements can also alter whether something is regarded as adequate or inadequate - eg earthquake strengthening standards for older buildings are a good example.

Engineering isn't about perfection (it can't be), it's about designing solutions that satisfy requirements and specifications as best as possible within constraints while juggling inevitable tradeoffs.


It in no way realistically ran into any constraints that were not arbitrary.

You seem to think that every constraint in the world can be removed by more money.


Generally more design time and more money can remove most constraints -- you just end up with a product no one is willing to purchase.


Which renders it all moot as the goal is to produce product that actually get used.

Fantasy products are impractical due to costs and generally a lot of other assumptions.

Toyota got known for cars that were good and cheap but not so fast in the 70's and 80's. Their cars quite simply did not break down.

Detroit made cars that were not as good, but were quite fast and comparable in price. Way different set of tradeoffs.

One was utilitarian and efficient and reasonably safe. The other was VROOM!

A look at the odometers from that period revealed very few manufacturers bothered with anything over 99,999 miles. Many American cars would not go that distance without requiring some very significant service, or encountering some critical failure. Timing belt, pump, etc...

The Toyota cars would go much longer times between failures, and those tradeoffs have played out in the market.

Today, big American cars aren't as cheap, they still are pretty fast, and pretty good. I've an SUV that's going to demonstrate a service life profile very similar to that old '89 Corolla, both of which I probably won't retire until 400K miles.

The vehicles are that good now.

So that triangle can bend, and it's not binary as others have mentioned. It's a continuum where a whole bunch of things are always moving and changing.

The other thing about time and money is how the markets play out. Sometimes it's good. Apple took that path a few times and ended up with nice margins and in some cases great share. In other cases, modest share, but margins that are worth it.

Fair enough.

Other times, being that late to market may well render the time and money expense moot as the use value is already being actualized in other products, leaving a superior entry with a saturated market that has very little incentive to purchase again.


Sure, with infinite time and infinite money you could make a perfect car. But even if you think Toyota has infinite money, they definitely don't have infinite time.

Time is a cardinal constraint. Money can buy time, but only so much.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: