> ...the flaws that led to Denver's death were the work of the builder, and had nothing to do with Burt Rutan [the original designer]. These flaws led from the builder's sincere desire to improve on Rutan's work, a goal that could actually be said to have been accomplished from an engineering perspective, even if it did kill the pilot.
> We in the PC and web worlds have a lot to learn from this, too. We have a lot of bad design floating around that is just as perverse as fuel valves that face the wrong way, hidden behind firewalls...
I agree that we have a lot of bad design in the PC and Web worlds, but I don't think that's the conclusion I'd draw at the end of the article. It seems like this a lesson about an engineer changing the design during implementation without understanding (or while misunderstanding) the original design. Chesterton's fuel valve.
It's not a misunderstanding of the original design. It's ignoring it completely.
It's someone unqualified to be making engineering decisions engaging in an absurd level of optimization for one rare (to the point of being nonexistant) risk, to the point that they made a valve that is part of near constant use in many planes...nearly impossible to see or reach.
Alternating what tank you draw from is part of normal aircraft operation because otherwise you end up with balance issues. Making that valve require contorting oneself and fully deflecting a flight control surface is so asinine it defies belief.
I don't even understand how the builder thought this was a risk in the first place. Fuel lines are always at a minimum protected if not run outside the cockpit, ie firewalled.
That's not true at all. My airplane, which is a Part 23 certified, factory-built aircraft that was made by Grumman-American, has numerous fuel lines running through the cockpit, and none of them have any fire protection on them, not even firesleeving. They are made from aluminum and copper, which are not considered intrinsically fireproof. That's also the case for every Piper and Cessna aircraft that I have worked on, which are typically older CAR-3 certified designs.
I would say that engineer may have a perfectly valid reason to do it, and it may be even a better overall decision, as was indeed in this case, preventing fuel pipes in the cockpit as I understood from the article.
What is often lacking is testing of significant changes before giving final result to the user. And that, together with writing documentation and training is often deemed uninteresting and boring by engineer rich teams. "Community will fill up gaps" is often heard. Well maybe. And maybe community will write an accident analysis after something bad has happened.
This highlights the importance of SOPs, training, checklists etc.
What's the value of a unit-less fuel gauge? Why not a warning light or two per tank and / or a calibrated fuel gauge?
If you want to move the fuel hoses out of the cabin (good plan!) move the fuel hoses out of the cabin but leave the interface in place and make it electrical; put the mechanical switch in the difficult to find place and update the SOP to include "if the remote fuel switch fails use the mechanical switch in this difficult to reach location"
Engineering around edge cases is hard. Which is just simply saying "engineering is hard". Doing things without addressing edge cases is just craft.
My college engineering curriculum dedicated an entire class to the topic of failure modes, edge cases, testing, SOPs, etc., and it was something professors in multiple departments took pains to teach us (and warn us about)—even in the humanities and arts. Hell, even just putting units on everything was something my teachers drilled into us since grade school. That education has informed every aspect of my professional practice.
Now that I am old, an important part of what I do is teaching others what I've learned, because if experience has taught me anything, it's that people don't just magically figure things out. Formal education and mentorship are as vital to my younger colleagues' success as they were to mine.
If you want to make a change, you must solve the WHOLE problem, not just the part you want to solve.
You need to make that valve easy to operate, operate in a sensible way (flip right to the right fuel tank, not left tank, have a 'both' setting, etc.), and make it ergonomically work.
In this case, the ergonomic issue could have been solved with a "dead pedal" right next to the right rudder. This is a fixed surface adjacent to the pedal in the cockpit wall you can put your foot on and press. There is one to the left of the clutch in most well-setup sportscars. With this, the pilot could press and reach around without any input on the rudders.
But, this "builder" couldn't be bothered to actually solve the problem and he killed a bunch of the pilots using his update, including John Denver. Criminal, if you ask me.
The testing bit is kind of huge. With most computer UI usability is fairly easy to test and, obviously, failures far less consequential.
I also wonder if the builder also made a faulty assumption that the plane would be flown mostly by experienced pilots in which case they may not have done a great job anticipating edge cases.
At college one professor used a particular engineering class to weed out students from the engineering program. He intentionally made it so challenging it was considered its own prerequisite.
I found the practice abhorrent even in that context.
Agreed. When my girlfriend was on a pre-med track in college, I distinctly remembered that she graduated with her biology degree knowing the diameter of a mouse hair cell but not knowing what the liver did. She graduated sumna cum laude, but did not have a good systemic understanding of the body at all. And the reason was that premed programs were designed to weed out the kind of people who couldn’t memorize vast quantities of information.
You don't just get to override Burt Rutan's design because you have a "perfectly valid reason to do it." For something like an aircraft you need to prove beyond a reasonable doubt that your way is better and you've thought of everything he did, or build it to spec.
It's an experimental amateur-built aircraft. The builder gets to do nearly anything they want to do (usually) even if it's a bad idea, and most of them have minor changes from the original plans.
The design change was possibly an improvement when the only user was the builder who was intimately familiar with its design, but ended up being a disaster when someone else tried to use it under stress.
You do, and this is why the FAA makes you put EXPERIMENTAL in big letters in the cockpit. If you want proof beyond a reasonable doubt that the plane is safe, get a certified aircraft.
IMO the FAA strikes an excellent balance between allowing people to make crazy flying contraptions that can be dangerous, yet also keeping the civilian flying population safe. One place where there can be some unanticipated risk though is, like in this case, a homebuilt aircraft that's sold to a non-builder.
In any case though, in my opinion, the primary cause of the accident was not the fuel selector, it was John Denver's lack of preflight. He took off with very little gas in the plane, and virtually none on the tank he had selected for takeoff.
We got a new car. It comes with a touch screen instead of physical controls. We really wanted to avoid the screen, but ended up settling on the least offensive / most likely usable for us car vehicle. There was nothing out there in new car land that we liked.
It is no longer safe doing simple things such as turning on/off recirculation.
We like fresher air, so generally want recirculation off. However, it is not uncommon to see a truck in front of us suddenly belch a lot of smoke.
In the old car, this was no problem. Push the recirc button and keep the bad stuff from getting into the car.
In the new car, that would require hitting the correct button near the bottom of the screen to cause it to bring up the environmental controls, and then hitting the right button near the now top of the screen to toggle the recirc. Totally unsafe when in traffic.
Add to that the settings that don't stay set every time you turn off the car, requiring manually going through and setting things up - it's not only unsafe but horrible.
It's amazing how car manufacturers have captured the frustration of navigating through your locked mobile device to do something arbitrary while driving and embedded that experience directly into the dashboard.
We have laws against using phones while driving for very good reasons everyone understands.
And then car manufacturers decide to make turning Air Condition on and off into a experience as much distracting as using a smartphones, so they can save a couple hundred dollars in a 30.000 dollars vehicle.
And because accidents caused by stupid car UIs are not as obvious an newsworthy as texting and driving, no politician has decided out that pushing for legislation for tactile controls can give him votes, so, nothing is done, legislation-wise, to curb this practice.
> And then car manufacturers decide to make turning Air Condition on and off into a experience as much distracting as using a smartphones, so they can save a couple hundred dollars in a 30.000 dollars vehicle.
Do they really save "a couple of hundred dollars" by replacing physical controls with touchscreens? I would guess they'd save less than a hundred per car.
Making serious user compromises to save a few pennies is totally something companies do, but I think they touchscreen fad is a bit more complicated than that. I think there's also an aesthetic factor, where they're chasing a "minimalist" and "high tech" look--which in recent years has meant flat surfaces and screens.
IMHO, it would help a lot of buttons and knobs start to be seen as a kind of desirable luxury feature instead of "old fashioned."
I'd guess it's closer to one hundred than multiple hundreds, but if you fully replace the HVAC controls with touchscreen controls, you save money on a bunch of things: hvac controller has fewer pins; you don't need to supply the buttons / knobs; you don't need to design, build, and install the wiring, harness and connectors for the buttons; you don't need to provide a hole for the buttons and mounting facilities behind the hole for them; you don't need to provide a trim for around the buttons; etc, etc.
Buttons cost money for each unit sold, stuffing the functionality into a touch screen interface that you're almost certainly going to have anyway only costs R&D money (and owner frustration, but if everyone is doing it....). My favorite though is buttons that only work when the touch screen feels like it; my Fiat Chrysler van has those for HVAC, you can press the temperature up or down buttons, and it'll queue the keypresses until it's ready to use them; sometimes many seconds later.
Cars never bought the cheap buttons as they wear out too quick. So each button is $.50 each for a good button. Then the have $3 of wire added to the wiring harness. Add $.20 for the connectors (they use the more expensive sealed connectors now). Each button is installed by hand on the car, so add some cost for labor. It all adds up. Note that while I don't know the actual costs of the above, I think the above numbers are reasonable.
A touch screen is $100 or less in the quantity they buy, and it comes as an assembly that replaces the radio they have to install anyway.
GM sold 6 million cars last year. If they can save one dollar on each that is $6 million dollars to the bottom line.
I think the, maybe contrarian, argument for this is that while a lot of the previously physical controls are now obnoxious to find there are a lot of features involving music, phone and maps that if they weren't on the dash people would be go ahead and just be using their arguably more dangerous phone to control.
There needs to be both dashboard screens and physical controls and knobs, if done right it would even look more "sleek" than the pure touch screen dash displays they're producing now.
It's a beautiful vehicle on many ways. But as so often, the desire to use touch controls has compromised the ability to drive without taking eyes off the road
The most egregious example is turning off the climate control. I need to look down and locate the "fan down" control, which is small and on a touch screen with no tactile features, then click it repeatedly until reaching zero and the air stops.
Piss poor design and dangerous for one of the most frequently performed tasks.
I find it interesting that America's product liability attorneys, the same who got the Piper Cub declared an unsafe design and more or less shut down the light aircraft industry, are so utterly ineffectual against the vastly more pervasive threat to public safety of such eyes-off-the-road design perversions applied to essential controls.
Since no one's mentioned it, another interesting incidence of this was when Anton Yelchin (who played Chekov in the newer Star Trek movies) died from mistakenly putting his Jeep into neutral when he thought he put it in park. Chrysler was using a new (and overclever) shifter design where you couldn't easily confirm by look or feel what gear it was in, and so was prone to being misidentified.
I rented one of these Jeeps a few months before Anton Yelchin's death, and my first reaction that was that it was an accident waiting to happen, that I expected to see a rash of senior citizens driving though storefronts because of it, and that I would avoid parking near them in the future.
One of the biggest issues is that not only does the gearshift lever not move to indicate the selected gear, but that the gearshift lever has multiple modes of operation - a short press would select reverse, but a long press would select drive.
So... 114 of these crashed according to Wikipedia. That's quite a lot for an experimental type. It doesn't say how many were built but it's pretty severe.
I agree in this case it was a nonstandard modification that caused it but still this does not seem to be the safest type to fly.
One thing I also read was that the valve was very hard to turn in this case. Which is probably something that he shouldn't have taken off with in that state. Especially because this was not even a thing that came out of the blue, it was noticed during precheck and the owner even said he never turned it during flight because it was so difficult. Meaning in my opinion that it's wholly unsuitable as a control with critical importance to the flight process. Especially for an aircraft without a "both" setting.
It looks super cool though, I'll see if it exists for flight simulator.
PS the jail number was N555JD, sounds a bit like a movie.
> One of the eye-opening stats was that most accidents involving EAB aircraft happen very early in the airplane’s life, often on the very first flight, and early into that flight. Pilots who survived EAB crashes often said the engine quit or lost power, or that pitch control on takeoff or climbout was not what they anticipated.
In the US 51% or more of the construction must be done by the original owner/pilot and they must also complete the first flight and subsequent test flights themselves. These test flights must follow a plan submitted by the pilot and approved by the FAA, but that is a fairly routine/templated process when building from a known kit. If your build deviates from the standard kit you can expect the FAA to require a longer/more rigorous test flight plan.
The test plan is usually focused on verifying the engine and flight controls operate as expected and documenting the stall speed/characteristics for that specific airframe.
That's around 1 in 8 registered airframes. The derived designs were even worse, 6 of 31 berkuts have crashed.
Ultimately a big factor is they aren't usually built as kit planes but rather full scratch builds. Each builder is independently sourcing materials and composites are very unforgiving. Kit planes are generally not that bad as the number of ways you can fail in construction is relatively well bounded and there's a lot of feedback into the design side to mitigate these common errors. I'm working on an RV8 and the errata is really something to behold. It's an older 90s design but the factory is still changing parts out on me occasionally as they discover issues. This is much more in line with how certified aircraft work so it stands to reason that they would enjoy a better safety record.
There's such a thing as over-optimization. So many people cannot see past their own justifications. Had the original builder of the aircraft stuck to the plans instead of trying to be clever, a life would have been saved.
Multiple Long-EZ's that failed over water ditched without injury.
About 95% of all private plane crashes are due to running out of fuel or flying into clouds. It is ridiculously easy to do neither: fill your tank, and turn around.
As for design changes, builders have tried hundreds of modifications to the Long-EZ design, and many of the successful ones are now the standard of care.
Indeed, unlike software generally, there is usually a strong and clear standard of care for each experimental plane model, as voiced by the builders with the most cogent explanations coupled with their own flying safety record (benevolent dictators eating their own dog food). The experimental aircraft community differs precisely in that everyone who flies their own plane is not the chicken but the pig (and builders who talk a great game are ignored).
> About 95% of all private plane crashes are due to running out of fuel or flying into clouds. It is ridiculously easy to do neither: fill your tank, and turn around.
Denver was told by a technician that the tanks had "less than half in the right tank and less than a quarter in the left tank" These are each 26 gallon tanks. The technician was wrong because the gauges were non-linear (and had no markings). Denver should have checked himself (and hopefully knew the gauges were non-linear), but either didn't check or didn't know. 10+ gallons (what he likely thought he had in the right tank) is more than enough for the flight he was attempting.
I love John Denver's music and I am still haunted by his death, 24 years later. I had no idea his death was likely the result of poor user ergonomics. Engineering can kill.
Interesting read, I remember the crash but never heard what happened.
Quote of the day from the article about the early days of Autos:
>Car fires are a common enough occurrence along America's freeways. A gas line breaks under the hood and soon the engine is engulfed in flames. The cure? Pull over, get out, find a long stick, and start roasting marshmallows.
I actually used the fire extinguisher I used to carry in my ‘79 Buick LeSabre to put out a fire but I ended up regretting it.
Smoke started pouring out from under the hood, so I pulled over and popped the hood and saw a blazing fire. I ran in a panic to the trunk, got the extinguisher, and put out the fire.
It turned out that the air conditioner compressor had seized up and stopped turning, causing the belt to overheat and catch fire. The fix was simple: remove the remains of the belt and everything was fine. Roll down the windows when it’s hot.
If I had let the car burn out and be totaled I would have saved a lot of trouble, including endless transmission leaks and a busted U-joint which led to my coasting to the side of the road with the driveshaft (connected only at the front) dragging and bouncing and throwing up showers of sparks down the freeway.
Yeah. I started carrying the fire extinguisher because my parents’ full-size Chevy van burned up with all of their camping supplies, clothes, guns, etc. from a three-month roadtrip. Also melted the front of their trailer before the highway patrol arrived. Brave/insane CHP officer pulled the propane tanks off of the trailer before they blew.
I had nothing of value in the Buick.
Ironic, as Ms. Morissette would say.
My parents bought the Buick from my grandmother to drive home to Virginia after the van fire, and they gave it to me for my senior year of college. My fire was a couple of years after graduation.
If your car catches on fire, you don't want it back. Get everybody away from it and call the fire department. Hold your phone horizontally when you film it for YouTube.
I used to do this. I redid my fuel lines and needed the correct type of extinguisher in case something happened during that. Then I just kept it in the car for years.
I know many of my friends who used to race cars and needed one in the car for certification/regulation continue to do so in their civilian cars to this day. Once you've done it because you have to, you realize that it might be a good reason to do it when you simply can.
The first "new" car I ever bought had a rubber gas line under the hood that was never properly clipped into place. It rubbed against the edge of the clip until eventually it cut through the line causing a leak. Fortunately I smelled the gasoline before it caught fire.
I don't buy new cars any more. I buy well used ones, they are the survivors, and someone else pays the depreciation and finds the lemons.
> I don't buy new cars any more. I buy well used ones, they are the survivors, and someone else pays the depreciation and finds the lemons.
Yes, exactly, right there with you. A good car will still be good after 10 years of use. Any car that isn’t worth buying at that point isn’t worth buying to begin with.
Fortunately gasoline will generally evaporate in moderate heat rather than ignite! Unless there is another ignition source which might be common enough on a poorly maintained vehicle. I've driven cross-country with a leaky fuel rail, would not recommend!
I had a friend who had 3 cars burst into flames inside of two years.
It was the strangest thing, engines caught on fire out of the blue. Admittedly, he was pretty poor (we all were at that time) and his cars were old beaters, but that didn't explain how three different cars could have their engines set on fire out of the blue in such a short time period.
The strangeness of this situation finally revealed itself when I witnessed him checking the oil on his car. It was low, (they all burned oil) and he had some on hand to top it up.
I watched him open a bottle and dump it into the intake, spilling copious amounts before getting it settled in.
He was basting his engines in oil. No one ever taught him to use a funnel or told him he might want to clean up spills like this.
When you make something idiot proof, the universe makes a better idiot.
Not OP, but I'm going to guess confusion between "intake" and the hole in the valve cover where oil goes. I say this because I imagine the result of pouring it into the intake is a non-starting car, not a fire. Cars don't run on 10W-40.
Sure they do. Not very well, and you mix it with gas, but they will run. 2 cycle engines sometimes run 16:1 ratios of gas to oil (an engine old enough to run 16:1 was speced before modern two stroke oils and so they meant regular engine oil - though oils then were very different from modern engine oils). Up until the 1980s a car with more than 70,000 miles on it could be assumed to burn a quart every few hundred miles.
I've never tried it, but I think my 1930 all-fuel tractor could run on 10w-40. I've run it on "it used to be gasoline 4 years ago", ethanol, and diesel.
Well the comment about it "burning a lot of oil" could also be attributed to splashing some oil in the air intake. And it might eventually leak somewhere hot enough to burn.
I agree odds are intake means... oil orifice in this case. But I figure we're already in car abuse land might as well see how deep the rabbit intake goes.
Ironically, if the OP had used straight 30w or 20-50w it would have run out of the car slower causing the car to take longer to catch fire because of less buildup of spilled oil.
I kinda doubt that. Automotive oil will cook off long before it ignites. You need to introduce liquid oil to a red hot object to get flame as a result. The chemical properties that lend themselves to oil that lives a long time in an engine or transmission also result in really high ignition points. If spilling oil could reliably cause a fire you'd see OEMs casting drip rails into things in order to prevent paths direct from leaky gasket to exhaust components.
I understand your doubt, but I assure you that I did not come onto the internet to lie today.
After I saw this I pulled him aside and asked to take a look at his engine and there was a thick layer of baked on oil on the side with the oil filler, and that oil was contaminated with thick clumps of dust and dirt from a general lack of maintenance, which in retrospect might have acted like a wick.
It took a full can of degreaser spray and a lot of vigorous wiping to remove the majority of it, and after doing that along with the exhortation to use a funnel when adding oil, the car engine did not burst into flame again. (He had become very capable in quickly detecting and extinguishing engine fires before they caused enough damage to the vehicle to disable it)
That car lasted a good two years before he wrecked and totaled it.
Petrol boils off too quickly to be a massive problem, it's vapour and gone before anything happens.
Brake fluid has a high boiling point, a low flash point, and it's sticky. Burst a brake pipe and spray that onto a hot exhaust and you've got a great source of fire.
I know from personal experience that if you can get the exhaust manifold hot enough (like, dull red) and you pop a coolant line, the water will boil into steam leaving the glycol antifreeze which will burn with an acrid greenish flame.
I doubt there are very many true electrical fires in ICE vehicles. Even if there is an arc, you need some kind of fuel to get a real fire going. Sometimes that might be the rubber/plastic components. But I feel like it's more likely to just be the ignition source for a fuel leak.
Many automotive plastics have fire retardant additives. It's certainly possible to have an entirely electrical fire. I just think it's a much lower rate.
I don't know what to tell ya, I assume I'm not an exceptional case. Maybe the characteristics change after 25+ years of use and multiple hundreds of thousands of miles.
John Denver was an experienced pilot who owned multiple planes with 2,700 flight hours. Unfortunately, on this particular experimental plane with an odd setup, just an hour or two.
I would recommend not reading the coroner's report on how he died. (Chalking this one up to one of my late-night insomniac excursions down a rabbit hole.)
At least it was quick. It was absolutely not pretty, though.
He was (is? somewhere? maybe?) an amazing dude who pushed hard to get his music accepted
> If you approach software design the way experts in commercial and military cockpit human factors approach their craft, you will end up with designs that are fast, familiar, and forgiving. Such designs would be a refreshing change in the ghastly world of PC software. They'd be a refreshing change in the world of general aviation, too.
This completely ignores hundreds or even thousands of required flight hours. If I required my users to train for hundreds of hours before using my software by themselves, I would make all sorts of different UI design choices. In fact, a command line or text UI interface might actually be the most productive. However, that is not the case.
Commercial and military cockpit design are all designed for the efficiency of the expert (especially military cockpits, since you do not want a “Are you sure” confirmation dialog during a dogfight).
>> If you approach software design the way experts in commercial and military cockpit human factors approach their craft, you will end up with designs that are fast, familiar, and forgiving. Such designs would be a refreshing change in the ghastly world of PC software. They'd be a refreshing change in the world of general aviation, too.
> This completely ignores hundreds or even thousands of required flight hours. If I required my users to train for hundreds of hours before using my software by themselves, I would make all sorts of different UI design choices. In fact, a command line or text UI interface might actually be the most productive. However, that is not the case.
Not necessarily. Your objection seems to be relevant to the "fast" part, but there's a lot of software that (for instance) just ignores familiar established patterns because the designer wanted to be different. It almost all cases, it would be a great improvement if they just stopped doing that.
"These flaws led from the builder's sincere desire to improve on Rutan's work, a goal that could actually be said to have been accomplished from an engineering perspective, even if it did kill the pilot."
It does look like this was a common change though considering there were 2 similar accidents before. Perhaps a community forum where this modification was proposed?
IIUC the two similar incidents were in the exact same plane (but did not cause a crash) not in a plane with a similar modification.
[edit]
> According to other pilots who were familiar with the airplane and/or had flown it, to change the fuel selector a pilot had to: 1) Remove his hand from the right side control stick if he was hand flying the aircraft; 2) Release the shoulder harness; 3) Turn his upper body 90 degrees to the left to reach the handle; and 4) Turn the handle to another position. Two pilots shared their experiences of having inadvertently run a fuel tank dry with nearly catastrophic consequences because of the selector and sight gauge locations[1].
Note "familiarity with the airplane" not "a similar Long EZ" which they use later to talk about investigators inadvertently depressing the rudder pedal when trying to use the valve.
Knowing nothing of flight except what I know from my pilot friends, my impression of Burt Rutan was that he makes killer planes because he was involved with the VSS Enterprise and then this and some other one.
Of course that's unfair because he's in the business of making experimental planes.
What I find curious is that this seems like the sort of field that would benefit from open-source design - flaws in design wouldn't be ported from other planes and shared visibility would benefit all. That makes me wonder if open-source software was inevitable after all. If it weren't for a bunch of early eccentrics, would we be primarily running binaries that we cannot edit? Good for them. Lucky to be in this field.
In aircraft crashes, there are usually a series of contributing factors to the crash.
I totally agree that the valve's design/position was the major one. But he shouldn't have found himself in a situation where he had to change fuel tanks just few hundred feet in the air.
I don't mean that in any bad way towards Denver. The world is a poorer place without him in it.
Tog is pretty famously on the "the mouse is faster than the keyboard" side of the debate, so it doesn't really surprise me that he's not enamored with terminals and shells.
There are a couple of reasons for this. First, unless the aircraft just suddenly fell apart, the pilot is always involved somehow. For example, in this case, the direct cause of the crash was the pilot providing a hard right (?) rudder input.
Second, and more cynically, the representation of pilots in the investigation is the weakest (and identifying the pilots as at fault causes the least economic consequences on everybody). For example, if you look back to when Airbus introduced the fly-by-wire system with moded inputs, their planes were dropping like bricks. (Including by the plane's test pilot at the Paris air show.) However, most (all?) of those incidents were assigned to pilot error in spite of the fact that an airplane that would change its flight characteristics or even conflict with pilot actions was a fun new thing.
You have an experienced pilot who knew the plane and its safety systems disable alpha floor protection before completely botching the approach. He could have aborted and gone around to get set up properly. But he didn't.
Instead he dropped to 30 feet on idle engine thrust, in a high drag configuration, and didn't press the TOGA button until 4 seconds before the crash. That's not enough time for the engine to spool up from idle.
I don't support prosecuting pilots except in the most egregious cases and I think involuntary manslaughter was the right call here.
Edit: The pilot claimed to have done this maneuver 20 times prior to the crash.
It then goes on to discuss the pilot's decisions that contributed to running out of fuel: failing to adequately plan and prepare for the flight, failing to refuel the aircraft, and setting the fuel selector incorrectly.
The next section discusses the actual loss of control, which is 100% on the pilot; he was too distracted trying to turn the glider he was actually flying back in to the motorized aircraft he wanted to be flying to fly it. That may sound harsh, but engine failure is a significant risk in single-engine aircraft, which pilots are generally expected to prepare for.
> And, indeed, the NTSB, as per its long history of setting aside findings, human factors or otherwise, that might conflict with a verdict of pilot error, ruled that the responsibility for this crash lay with the pilot.
> The valve: The builder not only placed the valve in a non-standard location [behind the pilot's left shoulder], he also rotated it in such a way that turning the valve to the right turned on the left fuel tank. This ensured that a pilot unfamiliar with the aircraft, upon hearing the engine begin missing and spotting in his mirror that the left fuel tank was empty, would attempt to rotate the fuel valve to the right, away from the full tank, guaranteeing his destruction.
So the builder intended you turn the backwards valve right, towards the left wing, and that activates the left fuel tank? This certainly sounds like a better human interface than turning the backwards valve left, towards the right wing, and activating the left tank.
Good point. I guess it's the pilot muscle memory with counter clockwise being left and clockwise being right that screws this concept up.
If the valve is in front of the pilot both methods match, if it's behind they are opposite. I could imagine this issue only becoming apparent in such a situation.
I think this aircraft should really have had a both setting though. Normally the fuel selector is only needed in case of leaks or unbalance.
> Just as with Unix, just as with DOS, the more confounding everything is, the better it is
Unix == confounding?
I'm sorry but even as a complete n00b and needing to buy "Unix in a Nutshell" in the early 1990's, Unix refreshingly made complete sense compared to DOS+QEMM+win3.1+IRQ's+spend all your time tuning and trying to get things to maybe work. It was like night and day.
Yes there were things to learn (hence the book) but it was easy and just worked.
Edit: referring to SunOS/Solaris on Sun hardware in the early 1990's vs DOS
Imagine if one were building a one-off vehicle and it had a critical control placed in an ergonomic spot with flammable fluid or maybe hot or high pressure lines routed through the cabin to necessarily reach it. What would the response be if they posted it to HN, Reddit, Youtube?
They would get harassed endlessly about how dangerous that it. You should "never" run fuel through the cabin. You should "never" run high pressure hydraulics near an occupant, etc. All sorts of low effort comments would be made to score cheap virtue points dunking on the builder. It would be one giant safety circle jerk complete with clipboards and safety vests.
And that kind of "I know the best practices but I don't deeply understand the requirements of this specific implementation" kills people, like apparently John Denver. This really should be sobering to many here. You could have been that builder. But what will we take away from it? Not the hard uncomfortable lesson to keep your mouth shut and don't touch anything in the name of "best practices" until you truly know the ins and outs of the application. Heavens no. We'll just make out our UIs suck a little less and call it good. That's much easier.
> You should "never" run fuel through the cabin. You should "never" run high pressure hydraulics near an occupant, etc.
Hah, I wish. I've run older construction equipment where all the control levers worked by actuating valves directly on the various hydraulic lines, with easily a couple dozen in- and out-let hoses routed through the cabin and through the control panel, each one full of high pressure, high temperature hydraulic fluid.
The worst was in the machines with inoperative A/C in the summer, those hoses might as well have been big radiator fins in the cabin.
Interesting article - but I find it odd that something published on a site devoted to interaction design should have such small text - and full-width at that. Currently using Firefox on Windows - I don't often have to touch the zoom setting, but for this one I had to crank it to 150% to read the article comfortably.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
Incredible that a site about design, interfaces and usability looks like a geocities page from the 90's. If the author is reading this page, sorry but someone had to tell you this.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
> We in the PC and web worlds have a lot to learn from this, too. We have a lot of bad design floating around that is just as perverse as fuel valves that face the wrong way, hidden behind firewalls...
I agree that we have a lot of bad design in the PC and Web worlds, but I don't think that's the conclusion I'd draw at the end of the article. It seems like this a lesson about an engineer changing the design during implementation without understanding (or while misunderstanding) the original design. Chesterton's fuel valve.