Hacker News new | past | comments | ask | show | jobs | submit login
USS McCain collision ultimately caused by UI confusion (arstechnica.co.uk)
476 points by tooba on Nov 2, 2017 | hide | past | favorite | 352 comments

There was a ferry accident involving a similar transfer of control problem in New York harbor.[1] Ferries have a lot of maneuvering modes and directional thrusters, because they do so many dockings, and so they have a more complex control problem. The pilot put the system into a backup dumb mode while in cruise, then changed stations to where he could best see the dock while still in the wrong mode. Rammed the dock at 12 knots. 79 injured, 4 seriously.

This is bad design. All the controls that can steer the ship should be tied together and move together. How to do that was figured out decades ago.

The Navy still has this thing where they hate to give control of both speed and steering to the same person. The helmsman and engine room take orders from the officer that has the conn. But that officer doesn't actually operate the controls. Some enlisted sailors do. This dates from the age of sail and steam. Merchant shipping gave this up decades ago.

Back in the 1950s, the U.S. Navy built the USS Albacore. This was an experimental submarine to test out the teardrop-hull concept. It wasn't nuclear; it was just a test vehicle to see how such a hull form handled. It was expected to be more maneuverable than previous designs, so it was set up with aircraft-like controls. One person sat in the pilot's seat, strapped in facing forward, looking at aircraft-type instruments, and controlled all the maneuvering controls. It was a very agile craft.

The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers. To this day, the Navy sets up nuclear submarines so that different people steer, control power, and control buoyancy.

(The British in WWII tried to control aircraft with multiple people. As bombers got bigger, they wanted to put a senior officer in charge, but younger people were better pilots. So they had an "aircraft commander" back-seat driving, as well as a pilot handling the controls. This did not work out at all and was rapidly dropped.)

[1] https://www.ntsb.gov/news/press-releases/Pages/PR20140408c.a...

User interfaces have gone backwards decades in quality.

Look at your car radio in a 90's car. You didn't need to look at it to figure out how to push the radio button, turn the volume, anything. You could even adjust the bass on the fly with a bass knob instead of navigating to your "eq" menu to do it.

Now, you've got to look away from the road, realize what "mode" your in, you can move the menu around to the "audio" section, then "fm", then select a channel. And of course, it's a touch screen so there's no tactile feedback. But at least it's got PRETTY ANIMATIONS!

My Toyota Corolla will blast audio out of the speakers as it boots but the volume knob doesn't respond till it completely boots up. So you may start the car and have 5-10 seconds of blasting radio that you can do nothing about. GREAT JOB GUYS. A volume knob that needs to boot.

This is what was considered not only acceptable, but a "Feature" in a modern vehicle with hundreds of millions of dollars in investment and NOBODY thought to see if the radio interface was actually... efficient? It's not like people interact with the radio/music console in a car on a regular basis...

Or my 2001 Jetta. It was one of the earlier cars with "climate control". What that actually means is that to set it to heat, you have to tap the "plus temp" button a literal 20-30 times to get it into "HI" to force heat on. And then the day warms up and on your drive home you want AC? Tap it 20-30 times on the "minus temp" button. There was no knob for AC temp. They gave you 1 degree precision on a car that couldn't guarantee 10 degree temperatures. Additionally, the volume control for the car had digital buttons. That's right. Enjoy pressing up/down 50 times. No ability to rapidly change volume. So when you switch radio stations or to casette/cd and the volume is highly different you have to sit there pressing the button over and over. But, even then, at least these were BUTTONS that you didn't have to look away from the road to use. They had little tactile notches on them so you could feel around for them.

It's truly awful. The last time I bought a car I wanted to take a hammer and smash the freaking "screen" because the UI was such a POS (VW Beetle). A 20-year-old radio is a better audio system, and the cheapest smartphone is a better navigation system than anything that comes in a car nowadays. But I suppose the manufacturers think they can't sell a car nowadays without "teh shiny screen." And they might be right.

Automotive "climate control" has been around since the mid-60s, and the controls of the early versions were also far more straightforward; basically, one knob for temperature and another for turning the system on/off at various settings. Here's one from 1973:


I had no idea that automatic climate control (i.e. user just sets the target temperature) dates back to 1970, because it was not a standard option for low/mid-price cars yet in 90s (at least in Finland). Heck, my parents bought a Toyota Corolla in 2003 with no automatic climate control. Fascinating to see it implemented with old-style analogous controls. Same for 6-way power seat.

Indeed, it was originally only on luxury models --- Cadillac introduced it in 1964.


I thought most of YC HN was based out of/lived in a California bubble. Surely the rest of the commenters here have modern cars? I have a VW GLI that has climate control that beats the shit out of any car I've owned before it. There was also another posted complaining about their radio having to ''boot up'' before they could change the audio volume. I've literally never heard of these issues. This is ridiculous.

I know. I'm not saying they invented it. I'm saying that it wasn't a common feature on lower price cars.

That wasn't particularly early. I learned to drive in a used (but perfectly functioning, of course) '91 Lexus LS400. It was the make or break car for the new Lexus marque, and they put serious effort into the experience.

It has excellent thermostat-controlled AC and heat, and it was very easily controllable using dedicated buttons without looking away from the road at all. I wish modern cars (cough, Tesla) would put a tenth the care into UX.

Tesla's console is the embodiment of form over function for UI. It looks beautiful having a flowing button-free cockpit, but I'd rather be able to adjust settings without looking away from the road. Whatever happened to HUDs? It seems like a HUD with a dial on the steering wheel would let you have the best of both worlds.

Don't get me started about TVs. When I grew up our family TV turned on in seconds, and pressing channel up/down reacted in tens of milliseconds.

How long ago? My color CRT TV took a good 10 s or so to warm up the tube before you'd see much/anything. But at least it responded instantly, so you could spend that time walking back to the couch instead of waiting for some stupid menu. Instant and trustworthy response is basically gone from most appliances. I think it's a combination of marketing (has to look high tech) and cost (touch buttons are cheaper than mechanically interlinked toggle buttons.

I still can't tell if my computer monitor is on or off because I don't know the weird LED flashing code it uses to communicate that (Holy crap! appliances use something like morse code to tell you important information about their state! How did they get so needlessly cryptic? If there's no picture, I have to check all the cables and push the power button a couple of times to see what happens.

Web programmers are as much to blame too. Show me a web video player that has play and pause buttons that always do what they say when they say it.

> Show me a web video player that has play and pause buttons that always do what they say when they say it.

The only player which ever worked properly — even allowing the user to step through a video frame by frame — was part of Apple’s QuickTime framework.

Fun fact: QuickTime will be 26 years old in December.


mps / mps-youtube :)

We have some recent TVs. They have no buttons. Including power buttons. If you want to turn them on, you need the remote control.

The ones I've seen don't have physical buttons, but have nearly invisible capacitive buttons, at least for power/channel/volume. For most other functions, you do need the remote control.

To be fair, you weren't getting near-instantaneous full HD quality broadcasting with DVR support on your TV back then.

The problem is that there's no reason one couldn't design a TV that had both full HD and zero boot time with instantaneous channel switching. The reason such TVs don't exist is simply engineering laziness.

Mine is almost instantaneous. Except it's a lie because the TV is never actually off. It's "Standby" mode consumes a crap ton of wattage and the manual literally says "unplug it" if you intend to not use it for a long time.

Not to mention the damn spyware that's included with it...

> The reason such TVs don't exist is simply engineering laziness.

If your answer to the question "why can't a billion dollar industry provide me with instantaneous channel switching?" is "because they are lazy", you are severely misguided (at the very least!). There are hundreds of extremely talented engineers working full-time on these problems. If the solution were as easy as you propose, the issues would be solved.

> zero boot time

That's not going to happen, ever, but I'll assume you meant "faster" boot times.

Probably. Keep in mind that your average set-top box likely goes through a more complex secure boot process than most electronic devices you would ever interact with. Why? Because if people can run arbitrary firmware on a set-top box, your cable company would lose a shit ton of money.

> instantaneous channel switching

You are bound by the latency required to demodulate a signal being broadcast from some satellite ~30,000 km away from the receiver, decrypt the resulting stream, and finally decode it, all on the fly so you get a nice, continuous, stutter-free full HD broadcast.

I am no expert, so there is probably way more stuff happening behind the scene that someone else could probably shed light on. The point of my comment was to demonstrate that things can sometimes be more complicated than they seem at first glance.

> If your answer to the question "why can't a billion dollar industry provide me with instantaneous channel switching?" is "because they are lazy", you are severely misguided (at the very least!). There are hundreds of extremely talented engineers working full-time on these problems. If the solution were as easy as you propose, the issues would be solved.

The answer is never "engineers are lazy". The answer is, the company doesn't give a flying fuck about this problem and will actually prevent engineers from working on solving it, because they can sell you a TV perfectly well with this problem still present, and there's other work for engineers that makes TVs easier to sell than actually delivering a quality product.

When you change channels it has to wait for the next key frame before it can display video.

Booting a computer doesn't have to be slow, and that's even more true for embedded computers. But making the boot process fast requires very careful engineering, which is both a rare skill and also not very well supported by management for consumer products companies.

The distance to the satellite has nothing to do with it. You're using big numbers to exaggerate the problem.

Decrypting and demodulating have be as fast as the data is coming, otherwise the delay would grow until you never saw the end of the show. So that's not the reason either.

Yes, the MPEG-2 decoder in your TV needs to be fast enough to keep up with the transmitted data rate, but that doesn't mean that it has instantaneous stream startup times.

Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC A/53 video for as long as 700ms. It needs to buffer quite a bit of timing information and at least an I-picture frame before it can start displaying anything: http://www.bretl.com/mpeghtml/startbuf.HTM

Not only that - the overall standard has tight timing tolerances to keep video arriving at the encoder/transmitter in-sync with audio/video leaving the decoder in your TV. It's not like MP3 streaming where every client has its own buffer size and time to start playing depending on network conditions, bitrate, etc.

Having a reliable buffering process to keep receivers in-sync is a feature, not a bug.

And the way to solve this -- at least for the case of consecutive channel surfing -- is to have multiple decoders and multiple buffers. It's simply precaching.

Eventually you're going to run into RF limits, especially if the signal is coming in over the air.

You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?

I'd pay extra for it. I'd pay even more for a TV that didn't spy on me and that couldn't update its firmware without my consent. But I'm probably not the target consumer.

> If your answer to the question "why can't a billion dollar industry provide me with instantaneous channel switching?" is "because they are lazy", you are severely misguided (at the very least!). There are hundreds of extremely talented engineers working full-time on these problems. If the solution were as easy as you propose, the issues would be solved.

Simple solution: just put 10x decoders/tuners for most recently used channels. I don't think it's really an engineering problem but more about cost-effectiviness, i.e. not enough consumers are willing to pay the premium.

Exactly. Just having two decoders instead of one would drastically improve the 80% use case of consecutive channel surfing.

Some TVs including Samsungs have dual tuners.

However, even if the read-ahead tuner was perfectly predictive you'd still need to flip through channels fairly slowly, otherwise you'll outrun it - about a second a channel.

Fair enough, but you were getting useful fallback, the image quality progressively degrading, and even with almost no image, the audio was still intelligible. With digital boradcast, it's all-or-nothing: all is fine, all is fine, until the error correction can no longer save you...and you get soundless picture, with block artifacts. Very useful for emergency broadcasts, when anything unicast will be overloaded as well.

Wish I could get that...

Y'know how they say "don't touch that dial"? When I grew up, TVs actually still had dials you had to turn. The tuner responded instantaneously when you changed the channel. Now get off my lawn you damn kids.

Of course it did, you were directly manipulating the a resistor in its circuit. Getting the channel just right...and keeping it there...that was, of course, the flipside.

>So you may start the car and have 5-10 seconds of blasting radio that you can do nothing about.

What some people do is make an audio file consisting of several seconds of silence, and do whatever is needed (call it "AAA.mp3", or put it first in a default playlist) to have it play while the player boots.

But yeah, it's really messed up that that should be considered acceptable.

Microwave oven UI's are terrible but they weren't always that way. My old Amana had 5 controls: a knob for intensity (never changed it) and a knob for the timer, plus start, stop and light buttons. When the the start button broke we just jammed it in the "on" position with a penny making the UI even simpler: put the food in, and turn the knob for the time.


I don't have the same feeling. Different brands have different UI's, and some are as simple as "Press then numbered button for how many minutes of full power cooking you want"

Unless you want more than 10 minutes, then you have to press a different button and then type in the time. Fortunately, there are only something like 20 buttons...a big improvement over a knob and a button that is immediately usable by anyone.

What do you cook in the microwave for that long? You could also look at much cheaper brands/models. I find that cheaper products seem to be keeping older UIs and therefor staying more functional

I was mistaken, my microwave makes you press somewhat hidden button if you want cook something longer than 6 minutes, not 10.

Thanks for pointing this out.

As cool as my friends' new car's features are, I still love my Acura RSX. I can reach from the steering wheel to adjust anything on the console without taking my eyes off the road. No fuss, made for human hands, knobs and buttons.

Splitting command is still useful when maintaining control takes constant effort. If there needs to be a human in the loop maintaining and adjusting speed or heading, rather than using a 'cruise control' and letting an automated control loop maintain that setting, then it does make some sense to let different people handle it so that the person actually in charge can focus on what they need to do rather than the minutiae of that controller.

This was used on the America's Cup New Zealand hydrofoil [1]. Conventional designs gave a helmsman a wheel to control the rudder with a twist grip on that wheel which controlled the angle of the hydrofoils and therefore the ride height of the boat. On the New Zealand design,

> they've got control of the boat divided between three people, so that Peter Burling is just steering. You can see he's just driving Miss Daisy when he's going down the run. And there's a guy trimming the wing sheet [adjusting power], he's doing a relatively conventional job. But then the third man forward in the boat has got his arms in what look like biathlon bars and he's controlling both the daggerboards all the time. He's in charge of just keeping the boat ride height at the right level, whereas on the other boats it's the helm with his buttons and paddles on the wheel who's actually having to fly the boat up and down and do the steering.

This does leave just one person - the helm - with real control of the boat. The others are just maintaining the ride height and maximum power from the sail. In the naval model, the helm doesn't actually have control of the boat.

But I think that you're correct that a naval ship which would allow electronics to maintain speed and bearing doesn't require that, and the primary reason for retaining it is political desires from the brass.

[1] https://youtu.be/bAXA0mIXGmU

In the steam days, it was a major operation to adjust the output of an engine. Valve linkages had immediate effect on the output, but you also had to adjust the boiler heat input to keep the temperature within limits. Far enough back, there were men shoveling coal into the boilers who had to be told to slow down or speed up.

Do you think it's mainly bureaucratic inertia that keeps it separate? Or is there something more complicated about controlling engine power than I imagine?

On a nuclear powered ship, yes, since you still essentially have a steam engine, the engine telegraph (throttle) isn't actually linked directly to the engine.

On a modern diesel or gas turbine ship, no there's not. Obviously there are limits to what the engine can do still.

On a nuclear powered ship, yes, since you still essentially have a steam engine

Right, this is why when BAe lied to the UK claiming that the QE class carriers could easily be converted to cats'n'traps every engineer in the country said WTF? Because with no nuke where do you get either the steam for the catapults or the surplus electrical power for EMALS when you want to steam directly into the wind for deck operations? But our idiot PPE-educated politicians lapped it up and signed cheques for billions anyway...

The nuclear part isn’t just used to generate electricity for the motors?

If https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh... is correct, then at least the Ohio class submarine drives the motor directly off the turbines, but the thing being designed to replace it will use electric motors. And actually, https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... talks about the same, but with some comments about the few submarine types that do this so far. And following the link to https://en.wikipedia.org/wiki/Integrated_electric_propulsion gives us https://en.wikipedia.org/wiki/Integrated_electric_propulsion...

Looks like some of the most modern or in-design classes are using electric drive, but most things out there are using direct mechanical linkage to the turbines to drive the propeller.

The heat from the nuclear reaction in a nuclear power plant is typically just used to boil water, which turns turbines, which creates the electricity.

Does this electricity charge a battery pack, which then is used to drive the electric motors which turn the screws? This would imply that the heat generation and turbine spin-up time merely need to respond before the batteries are discharged, potentially allowing response times of minutes or hours. It would give Tesla-like instant throttle response, where the operator would move the lever and the sub would jump forward.

Or does it directly power the engines? This would mean that your entire control loop would include the latency of the steam generation process. Move the lever, wait for the water to get hot, wait for the turbines to spin up, and then the screws would start to turn faster. Like the throttle response in an ancient diesel truck.

Given that the original diesel submarines used giant battery arrays to power the electric motors while the engines were off, and that the former gives much better control response, I'd assume that there are still large batteries in the loop. This paper [2] supports that assertion:

> The nominal cell voltage is 2.0 V. [1] The PDX-57 cell designed for Ohio-class submarines weights 2,100 pounds with a capacity of more than 10,000 Amp-hours and stored energy of 2.6 MWh. [1] The ASB-49 cell designed for the Los Angeles-class submarine weights 1,300 pounds with a capacity of 7,200 Amp-hours and stored energy of 1.8 MWh. [1] The LLL-69 type cell weights 1,500 pounds with a capacity of 8,100 Amp- hours and stored energy of 2.0 MHh. [1]

A couple megawatthours is plenty to run the screws while the steam loop and nuclear reactor respond.

Therefore, toomanybeersies comment:

> On a nuclear powered ship, yes, since you still essentially have a steam engine, the engine telegraph (throttle) isn't actually linked directly to the engine.

is technically correct but actually irrelevant. The nuclear reactor telegraph does control the steam turbine and eventually the battery charge, rather than the engine. But somewhere there's an electric motor controller which responds instantly.

[1] http://ieeexplore.ieee.org/document/1177196/?reload=true&tp=... [2] http://large.stanford.edu/courses/2013/ph241/ditiangkin1/

It looks like warships with electric drive are _just_ starting to go into production. See https://en.wikipedia.org/wiki/Integrated_electric_propulsion... and https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... for some background.

Both the Ohio and Los Angeles class submarines use mechanical linkage propulsion, not electric, if I understand correctly.

Your entire comment is wrong, and toomanybeersies is right.

Source: https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh...

The nuclear power plant is heating water to generate steam.

Which presumably drives a turbine to make electric which can run motors, charge batteries, run scrubbers, run heaters, etc., presumably.

They're not direct driving the screw with steam power from the reactor heat-exchange, surely.

It's hard to find anything like a schematic of a Nimitz-class carrier for obvious reasons, but as far as I can tell yes, it's all directly steam powered. The reactor boils (sea)water, which is used to power 4 steam turbines[1][2][3], those turbines drive the propellers.

You've probably seen aircraft carrier decks covered in smoke. This is because the Nimitz's catapult system is directly steam powered, service steam is widely used on the class. I can't find a citation for this now (this is from memory) but I saw some documentary on it once where it was mentioned in passing that even the washing machines on the ship were steam powered. There's service steam everywhere on the Nimitz.

Having steam power everywhere introduces a lot of complexities, which is why the Navy's moving away from it with their new carrier class[4]. The Gerald R. Ford-class does away with service steam in favor of more powerful electric generators. There'll be no service steam, just steam to drive the electric turbines.

1. http://www.nimitz.navy.mil/FACTS.html

2. https://en.wikipedia.org/wiki/Nimitz-class_aircraft_carrier#...

3. https://www.marinelink.com/news/dresserrand-propulsion302604

4. https://en.wikipedia.org/wiki/Gerald_R._Ford-class_aircraft_...

I love the way they did the electromagnetic catapult.


Basically they spin up flywheels that then dump their kinetic energy back into electric power as the catapult is released.

And it allows them to finely adjust the speed of the catapult depending on the kind of aircraft they are launching.

some nuclear submarines are not steam powered directly, they use electric engines.

Very few, if https://en.wikipedia.org/wiki/Integrated_electric_propulsion... and https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... are to be believed. The latter claims that as of 2013 there is exactly one nuclear submarine class (https://en.wikipedia.org/wiki/Triomphant-class_submarine to be exact) that uses electric engines.

> They're not direct driving the screw with steam power from the reactor heat-exchange, surely.

Yes, they are, for the simple reason that it's more efficient. This is beginning to give way to a series electrical design, but that's for reasons of increased stealth and other concerns, at the cost of overall thermodynamic efficiency.

On all existing nuclear carriers steam is used for the catapults (and this is much more demanding than many people are aware of). The Ford class is developing electromagnetic catapults, which are also proving to be demanding to perfect.

> Valve linkages had immediate effect on the output, but you also had to adjust the boiler heat input to keep the temperature within limits.

Can you not vent some of the steam, so the same volume of steam is being produced and the temperature the same but only some of it goes to the drive?

I think their point is that when changing engine output is labor-intensive, it made perfect sense to have an officer giving orders and somebody else implementing them. Why the command structure hasn't shifted to accommodate modern technology is an interesting question

It's not labor-intensive, it's attention-intensive. You want the person managing the speed to be focused on that. You want the person managing the heading to be focused on that. And you definitely don't want the officer to be distracted by maintaining course and speed when they need to be keeping track of what's going on around the ship.

You want the person managing the speed to be focused on that if managing speed is still inherently and unavoidably attention-intensive - if modern control technology is able to automagically maintain speed at x knots, adjusting all the various engine control parameters to implement that, then an extra person in the loop only means an extra chance for mistakes or delays.

If the military learned a lesson from exploding a reactor with an automatic control system, you might never know - it's not required to be reported to the public.

If an automatic control system can blow up a reactor so can the manual one. You have a problematic design issue in both cases. You can also still assign someone to keep an eye on the reactor in case things go bad an have that person pull an emergency stop or warn the guy in charge. There is no reason to relay every little speed change through several people.

This would mean wasting fuel, no?

What's that got to do with anything?

The comment was about the ability to vary power at all, not doing it efficiently.

Are you going to choose to crash into something because it's wasting fuel to vent part of the steam?

A basic of driving a steam engine is not to waste steam, since steam represents fuel, which in turn represents money. As you say, not having an accident is more important than wasting a bit of fuel (hence safety valves on steam boilers), but in everyday operation wasting fuel is a cardinal sin and something that is to be avoided. At one point I was involved in steam rail preservation, and the old-timers used to mourn the loss of engine driving/firing skills whenever engines sat at the platform with the safety valves blowing.

The ship command structure was a form of information hiding, whereby the commander only worried about the speed, whilst the engineer worried about how to efficiently deliver the requested speed.

> Are you going to choose to crash into something because it's wasting fuel to vent part of the steam?

Under emergency you will vent, but under normal operations where you just want to slow down you care very much about efficiency.

Not just for monetary reasons either (though that's a factor) but because the lumps of coal you're not burning now could save your ass in bad weather and make you reach safety instead of being stranded in the middle of the ocean.

At sea, efficiency gets you back to land.

I think if the same volume of steam is being produced then it's going to cause problems regardless

> Or is there something more complicated about controlling engine power than I imagine?

Large marine diesels such as used by container ships do need to follow a procedure to change out of the cruise rpm. I don't know how much that can be skipped/abbreviated in case of an impending collision, but I do know that generally it takes more than just someone on the bridge changing a control setting.

Yes, steam demand controls the power response of a nuclear reactor.

It makes some sense to me. Conning officer instructs helmsman which direction to go. Helmsman then executes that and monitors/adjusts to stay on that heading without further attention. Same for speed. The officer is then free of the tasks of monitoring and adjusting speed and direction and can focus on what's happening outside of that.

Looking for good models for ops team improvement, I was just handed the Watch Officer's Handbook. It encourages new watch officers to give rudder orders, not desired headings.

Depends on the context.

When maneuvering, you are watching obstacles and can see how much you need to turn to avoid them. So you give rudder orders. Your actual heading is only a secondary concern.

When navigating, you simply order the desired heading (for minutes, hours, or days). Then you focus on other things while the helmsman sweats the details.

Thank you. That's precisely why things are this way. Source: me, Navy veteran

What about the question regarding having one guy doing direction, and another guy doing speed? Is that called for?


Maintaining a ship's heading is a full time job. If you get distracted, you get off course pretty quickly.

Speed isn't even really handled on the bridge. The engine order (ahead full, back half, emergency stop, etc) goes to the engine room where multiple people do the work.

Note: This is in the context of oil and nuclear steam-powered ships. Gas turbine ships may well have an actual throttle on the bridge. Whether the bridge has a throttle or just an engine order telegraph, the helmsman can often have their hands too full to deal with it. But someone else can do it along with their other duties, as speed control is not so intensive.

As an outsider (well, I have plenty of experience with pleasure boats/yachts, but none with large ships) it seems really extraordinary that just maintaining a heading would be a full time job.

Somehow in airplanes a single pilot manages to control not only the rudder, but throttles, ailerons, elevators, flaps and whatnot while also yakking on the radio. And airplanes zip along at 500 knots rather than 20 like a ship.

Navy sub vet and almost licensed as a pilot: The small aircraft case - one mind, one set of hands, to reduce the feedback loop to fractions of a second overall. Things other than throttle/ailerons/elevators get timeshared in when all else is stable momentarily.

Larger ship - water is never still, and any vessel's helm left untended results in drift, both in heading and real speed vs ordered. Depending on traffic and the reaction time of the hull, corrections need to be made immediately or even well ahead of time. So helmsman watching constant compass shifts and adjusting steering is a full attention task. As is monitoring speed made vs speed ordered. Still need more eyeballs to keep a full 360 visual watch, radar watch, and a quartermaster to plot position against nav hazards and boundaries and warn against the 'invisible' navigation issues.

If a destroyer could respond to control input like a plane, there would need to be a single person at the helm/throttle.

I understand that keeping on a desired course is not a simple task and requires prediction and understanding of the surrounding waters... But you can say the same thing about crosswinds and thermal layers and pockets of turbulence in the air over a runway, and autopilots land 747s every day. In a far more computationally intensive and less recoverable domain, with more complex system dynamics and controls even discounting the extra dimension, plus sensing that's both more limited and harder to interpret. If modern controls theory can land an aircraft, I'd expect it to be able to run a ship along a trajectory like it's nailed to a rail in space-time.

TL/DR: I have to boil this down to a gut feel, but I'd rather fly a known takeoff/landing profile at any airport, than take a n-thousand ton vessel through a port departure/arrival, simply because the overall situation in the air is so much simpler.

Entering/leaving any decent sized port that handles larger vessels is a much more intense collision avoidance situation than any airspace management situation I can imagine.

Reducing the reaction space from three to two dimensions and extending the reaction time from control input -> output by a factor of 100 to 1000 is part of it.

The other complication is having a magnitude or more of different classes of "threats", from unexpected solid objects ( chart errors or new items unreported), other vessels both larger and smaller with faster or slower response times of their own, errors in SA... eyes and professional judgment help immensely. Thus the focus on keeping the OOD watching the whole SA.

My sub had at least a dozen people involved in building the "picture" around the boat, visual, sonar, radar... plus two or three of us collating that into displays and reports the OOD could see immediately.

I'm not advocating full autopilot; I agree that safe trajectories can be harder to plan in dense 2d than in sparse 3d, and that military ships in particular often have high-level objectives that would be extremely difficult to formalize for input into a planner.

Rather, I'm doubting that going in a straight line at a target speed is correctly handled with a three-person steering wheel. My understanding is that the current OOD already has a trajectory planned through the workspace coordinate system (space, time) and gives orders in workspace coordinates ("go this fast") that are then translated into low-level control outputs ("set the rudder to X"). It sounds like in some cases the OOD even gives direct control outputs - "Prepare for X thrust in Y minutes". Certainly these low-level controllers can't be a good thing for the OOD to be spending cognitive resources on, and I'd be astounded if we can't replace that with a computer that translates directly from that trajectory to the control outputs.

That's why I used airplanes as my example, rather than, say, autonomous vehicles. A commercial airliner's path through the air to a safe landing is basically hard-coded. The task of the airplane's autopilot, then, is simply to follow that trajectory - and I'd guess that it's far more difficult for an airliner to follow a workspace trajectory than it is for a ship to do so.

Really, the hard part is going to be getting the trajectory out of the OOD's head. And even then, it'd be so much easier if the helmsman could execute "go this way" by punching "this way" into a computer instead of staring at a compass and directly and continuously controlling the rudder.

Well said, that gives me a perfect frame to say that the inherent complication in handling the ship's trajectory is how rapidly the trajectory may need to completely change, contrasted against the reaction time of the vessel itself.

The OOD is estimating a best trajectory given an analysis of the navigation constraints and the behavior of every possible contact in the vicinity. Orders at every level of detail are possible at any time... from 'resume best course for point "X-Ray"' to 'allaheadflankfullrightrudderbraceforimpactport!'. That is the point of resistance to most levels of automation past 'ship's wheel mirrors rudder angle' and 'engine order repeater indicates desired engine rpm'.

Aircraft, even big ones, are still far more maneuverable than large navy vessels. That extra Z dimension gives you more space to work through problems, even if it adds complexity.

Fewer obstacles maybe? Also, with a fast plane you either land or take off, or do stuff in practically free space.

Also there is the example of infantry tank. There is the driver who has speed and direction. Then there is the commander who gives orders but apparently has backup system to drive if the driver is incapacitated.

A ship just can't have as much obstacles as tank negotiating battlefield.

> the example of infantry tank. There is the driver who has speed and direction. Then there is the commander who gives orders but apparently has backup system to drive

The UK's Warrior armoured personnel carrier is an example of what I guess you mean by 'Infantry Tank'. It has a Commander, Gunner and Driver (plus the 'dismounts' - seven guys in the back who get out to fight on their feet). The driver - as the role name implies - does all the drving. The commander (who is also the loader, incidentally) directs the driver where to go. He does not have duplicate driving controls. If the driver is very inexperienced, the commander will give him very precise direction. If the driver is experienced - in the sense of understanding tactical movement considerations - the commander can be much more hands off.

If the vehicle commander is also a platoon commander, he is also giving orders to the commnanders of the three other vehicles in the platoon. He is much more likely to be paired with an experienced driver so he can focus more on the overall battle than control of his own vehicle.

"Infantry tank" was my mistake. Those things only existed around WWII. Regardless any modern tank, infantry fighting vehicle etc. has single man controlling both speed and direction.

And in 3 dimensions (which a sub does too, but not a ship)

It may be on a US Navy warship, that absolutely isn't the case for other blue water navies. If anything I would suggest that having too many people involved adds confusion. The OOW has repeaters of the course and speed so that they can verify their orders are being followed, they are the check.

The Wolf Rock collision board of inquiry makes for interesting (and embarrassing) reading around what happens when assumptions are being made about who is doing what.

Especially if it's so easy to get off course, and since the responsibility lies with another officer anyway, steering sounds like a job better suited for a computer, rather than a person. As far as I know, airline pilots already dial in most navigational course changes to the autopilot, I would have imagined ships to work similarly.

That seems obvious today, but the McCain was laid down in 1991. Computers were much less sophisticated back then.

I wonder if there is enough information publicly available to compare the workflows on the McCain to the same workflows on the Zumwalt.

What I don't get is that obviously on a military vessel the chance of someone getting injured or incapacitated are rather high - so why would you want critical things like speed to be controlled by a separate person from the one steering? If they get knocked out and the controls for speed/direction/depth are in a physically different location, doesn't that result in a complete loss of control?

On the flip side, if there is an event that incapacitates one person it might not affect all 3 so you still have some control during and right after the event instead of waiting for someone to make their way to the control station

You could have 3 sets of full controls and personnel, that's more redundancy; you need lockout and takeover abilities.

That's how Star Trek do it!

Reading the raw accident report, I draw the opposite conclusion. The sequence of events that led to the accident started with one person controlling both steering & throttle. The reason for splitting responsibility is that the original helmsman was overwhelmed by the number of actions required to control both.

This reminds me of the Air France crash that was largely due to split control. The UX of transferring control of a system is difficult, and I don't know the details of what it looks like in an Arleigh-Burke.

Though the 2nd helmsman getting confused by having the throttles split points to training. That's ship control 101. I do think the loss of practical training is a root cause here. How many hours does the average helmsman have under their belt? It's just not that much.

To be fair, split throttles is not a sane or intuitive default.

> The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers. To this day, the Navy sets up nuclear submarines so that different people steer, control power, and control buoyancy.

After reading Ben Rich's Skunk Works memoire, and coming across some other references to the Navy's intransigence in some areas, this fits right in.

As a devil's…inquisitor, I guess— I'm curious what the reasoning has been behind the Navy's (and WWII RAF's) preference for split/seniority control and in what situations that balances out, if any. Are those situations where some known, serious risk of error is mitigated by sharing responsibility? Is betting on experience over skill actually wrong, or is their implementation misguided? Or just not applicable to those situations? (Fast situational awareness, etc)

It seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.

Article says:

> Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control."

If that's true and not just an excuse for an unnecessary command, then maybe it's still difficult trying to do both at once.

Part of the reason might be the variety of warship designs and handling characteristics compared to civilian ships. I would think it'd make it easier for Officers to transfer between various ships.

I do think the Navy has difficulty delegating and tends to try and focus power on a few positions.

I'm sure there's a good reason for the "tradition". Similar to a group of monastic monks following some bizarre ritual which could be done in a more efficient way. Someone from westpoint or the naval academy probably knows..

I’d say it’s the same reason why manual transmission vehicles are still more popular than automatic transmission in some countries. Automatic transmission of modern cars is easier (you can give more attention to the road than having to think about changing gears), gives a smoother ride, is more fuel efficient and causes less wear and tear on the engine.

It’s a habit that the organisation is used to, so there is resistance to change.

(I was born in one of those countries, and drove manual transmission for my first 10 years of driving, but am now a convert)

I drive a manual transmission car every day and I'm bemused by your reference to "having to think about changing gears". For an experienced and competent driver, registering and acting upon the need to move up or down a gear usually requires no conscious thought whatsoever. The mechanical process itself literally takes a split second. By contrast, in my one experience with an automatic transmission, it proved to be a constant distraction from the business of steering the car and enjoying the drive. That was because it was never in what I considered the appropriate gear, refusing to change up in a proportionate manner as I accelerated, or to change down quickly enough on upward inclines. It was teeth-grindingly irritating. Admittedly, that was 10 or 11 years ago, and perhaps the state of the art has improved since then.

Certainly it has. Having converted to automatic transmission recently, shifting is one less thing to keep in the back of your mind (even if it was second nature to me, after many years of driving stick). With the kickdown button, you don't even have to worry about getting enough power in emergency situations ("have I downshifted low enough?").

Even so, the stick driving reflexes only get dulled temporarily - within five minutes of driving stick, you're back up to speed again (pardon the pun).

I agree it's not something you really think about (I used to think automatic was for lazy people), but when you don't have to think about it, it's a load off your mind. This is exactly my point though - it's a habit that people are used to, and don't see why (or don't want to know why) changing it might be beneficial.

Automatics are usually less efficient than manuals - the Hydraulic torque converter has to slip to function.

That said, the automatic might beat a manual in other metrics.

A modern dual-clutch automatic* switches gears so swiftly and seamlessly that there is no feeling of clutching going on at all, if not for the motor tune or the RPM indicator you wouldn't know it's changing gears. If you disregard either it almost feels as-if the car is going from 0 to 180 in one gear.

* i.e. it doesn't have a torque converter, since it basically has two separate gear sets with two separate clutches. To switch gears it seamlessly moves between gear sets via the clutches. There is no interruption in power.

Torque converts are the niche choice nowadays, a lot of modern cars have dual-clutch transmissions which are always more efficient than manuals. They use less fuel, shift quicker and commonly have more gears for less strain and better efficiency(almost all new MB cars ship with 9-gear dual clutch tranmissions nowadays for example).

But yes, after owning manuals for years I would never go back, an automatic allows you to be so much more focused on the road and enjoy it more - I love driving and have a sports car, would never ever swap the transmission in that back for a manual.

I had the reverse experience of you, that is, I always drove automatics and then learned to drive manual later on. I actually felt I was more focused on the road in the manual because I needed to plan ahead for gear shifts. In an automatic everything is taken care of so it's easier for the mind to wander. I thought I was a better driver in the manual. I guess if I drove a manual for years it would probably go on mental autopilot more.

At the end of the day I think manuals are great fun but automatics are more practical. An automatic will never stall out in a safety critical moment, as I always worried I would do in the manual. I've also pondered that if I was ever to sustain a serious injury to an arm or leg, I would probably be able to drive an automatic in an emergency. Driving stick with a broken arm would be substantially more difficult. The fuel economy advantages enjoyed by manuals seem to have dissipated at this point as well.

Modern automatics are almost always more efficient. The biggest is that the torque converter has a lockup clutch during crusing, and often more gears and a near perfect knowledge of when to shift gear.

Do they break more often too? Like TCO is higher?

Automatics in UK certainly cost more, if one doesn't ride the clutch I imagine the manual will have lower maintenance costs?

Manual has lower maintenance costs regardless. A clutch plate is about $500, an automatic transmission is between $1500 and $4000. Manual doesn't require its fluid to be changed.

Cars with automatic transmissions cost more.

They cost more to buy, they cost more to maintain, and the more pleasant they are to use, the less reliable (e.g. VW DSG vs Toyota HSD)

I would be interested in seeing additional sources that support the theory that political machinations, not practical concerns, decided how many pilots a modern warship requires.

The Apache Attack Helicopter is renowned for being especially difficult to fly [1], and I wonder if Navy wished to avoid having a similarly single, not-so-easily-replaced bottleneck.

[1] https://www.airspacemag.com/daily-planet/hardest-to-fly-8713...

>>> The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers.

Which is why pilots in modern air forces are officers. It isn't about guarding traditions. It's about the level of training and responsibility needed when navigating a vessel. The Albacore operated in a totally different environment. Its "pilot" wasn't navigating in a busy shipping channel and could turn on a dime. The reason that the watch officer doesn't operate the control is because that frees him/her to concentrate on actual navigation, the forward thinking needed when operating a huge object that cannot turn on a dime. Civilian vessels at sea are going from A to B. For a military vessel (ship or aircraft) the A->B navigation is one of many different missions going on simultaneously. That's why they need more heads making decisions.

" ... did not have the right type of watch on duty for navigation in congested waters ... "and neither attempted to make contact through Bridge to Bridge communications."

The system did not fail. The system wasn't implemented. UI issues were secondary to the fact that this was an undermanned ship with an unconfident crew.

(An amusing note on ferry control. In San Francisco, at the Hyde Street Pier, there is a large steam powered car ferry boat, the Eureka, from 1890. That boat is powered by a double-acting one-cylinder engine driving both side paddlewheels. It's reversible, with some difficulty. It cannot get itself started at top dead center or bottom dead center. So there's a giant pry bar, about eight feet long, which can be used to get it started. You can see this hanging on a bulkhead near the engine.

Think about operating this turkey. This car ferry docks nose into the dock, not parallel to it. You're coming into the dock, and have to stop and reverse the engine to slow. If the stopping and reversing operation results in the engine stopped at dead center, there's no power until the crew frantically gets the pry bar and levers the engine into a position where a power stroke is possible. Screw up and you crash into the dock. It's a ferry boat, so it docks a dozen times a day.

Now that's a control problem.

The Eureka is the last surviving example of this design. Other paddlewheel ferries were built, but usually with multiple engines or multiple cylinders.)

So do other navies have a single person steering their ships like you advocate?

Do you have references for the Submarine story? The submarines I've seen have a rudder, stern plane, and another on the sail. With mechanical controls, I imagine it's difficult to have one person control all three of those movements. Two people controlling three movements seems right.

The Albacore museum has a virtual tour, it shows 2 seats:



But it was modified several times, so that doesn't really contradict the story.

See [1], the section on "The Pilot".

Albacore was very maneuverable, probably more so than any large sub before or since. The term "hydrobatics" was used. Probably too maneuverable for a ship of that size, since it wasn't configured for operation with everybody strapped in.

[1] http://www.ussalbacore.org/html/albacore_story.html

It looks like steering was controlled by one person. Unfortunately it lacks further detail. I saved the link to read later. Thank you.

thanks for this comment!

A great reminder that "the way things are" often are just accepted, never questioned, even ritually enforced; all while drifting further and further from better ways.

I think this whole text, but especially the paragraph about British WWII is a good example of what "Military Intelligence" is about

Split command also provides plausible deniability.

“No, we did not deliberately ram a ship suspected of smuggling contraband to North Korea, that would be illegal.”

The real cause of the collision was poor seamanship and failure to follow the COLREGS on the part of the bridge crew of the destroyer. Most specifically they were seriously in violation of Rule 6: the Safe Speed Rule


  Every vessel shall at all times proceed at a safe speed so 
  that she can take proper and effective action to avoid 
  collision and be stopped within a distance appropriate to 
  the prevailing circumstances and conditions.
The USS McCain was traveling at over 20 knots at the time of the collision, through a very crowded area at the entrance of a traffic separation scheme. If they hadn't been traveling at this obviously excessive speed they would have had the time to think, and to work through little UI issues like the one described here.

The path to a disaster has been compared to a tunnel [0]. You can escape from the tunnel at many points, but you may not realize it.

Trying to find the 'real cause' is a fool's errand, because there are many places and ways to avoid the outcome.

I do take your meaning, reducing speed and following well established rules would have almost certainly have saved them.

0. PDF: http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...

Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error...

I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit...

In a lot of fields where the stakes are high and mistakes are costly (aviation and emergency services are the two I'm most familiar with) the analogy used is a chain. Break any link in the chain and you prevent the event.


It's the perception tunnel. There are many branches, but only one route is followed. In hindsight, you can see all the branches and call out everything that went wrong.

Normally that is called "tunnel vision".


(figuratively) The tendency to focus one's attention on one specific idea or viewpoint, to the exclusion of everything else; a one-track mind.

> I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit...

Road and train tunnels have many emergency exits...

Generally they have a parallel tunnel (either for traffic in the other direction, or specifically for emergency egress), and connections between them. They still take you to the same general place.

I think the idea is that if you are stuck in a dark train tunnel and there's a train coming towards you, there may be doorways, recesses, etc in the walls that are invisible without the proper tools (flashlight, etc).

Urban tunnels have many regular entries and exits, as well as emergency exits, not to speak of emergency crossovers.

I prefer the swiss cheese model.


"In the Swiss Cheese model, an organisation's defenses against failure are modeled as a series of barriers, represented as slices of cheese. The holes in the slices represent weaknesses in individual parts of the system and are continually varying in size and position across the slices. The system produces failures when a hole in each slice momentarily aligns, permitting (in Reason's words) "a trajectory of accident opportunity", so that a hazard passes through holes in all of the slices, leading to a failure."

A series of minor failures that combine for a serious crisis seems very relatable.

Yup! My cousin & cousin-in-law work to maintain human health at some nuclear power plants in Canada. They use the swiss-cheese model, and whenever they notice that one layer missed something, they do a re-evaulation of that safety layer.

Aha! I sense an opportunity for an enterprising statistical physicist to model this with https://en.wikipedia.org/wiki/Percolation_theory :)

As we say when teaching new riders to ride a motorcycle, a crash is often an intersection of factors. If you remove even one of those issues it likely would have prevented it.

I've noticed a lot of learners (eg in YouTube videos) crash because they grab at the handlebars, grabbing the throttle and inadvertently accelerating.

Is there a reason the throttle can't be reversed so that grabbing would reduce throttle and slow the bike?

(FWIW, I'm a fully licensed motorcyclist, don't currently ride.)

Are you recommending the 2nd edition specifically? There is a 3rd edition available: https://www.amazon.com/Field-Guide-Understanding-Human-Error...

No, I just didn't notice (speaking of confusing UI, Amazon seems to do everything possible to move UI elements small and large on a basis so arbitrary as to seem completely random)

A number of the worlds largest ferries - 50% longer than USS McCain - are routinely navigating in very restricted and crowded waters in the archipelagos of Stockholm and Helsinki with a clearing under the keel of just a few meters.

They seem to manage avoid colliding with both commercial traffic and the numerous sailing yachts while doing 18-20 kn.

Accidents have happened, but it's not recurring events. One exception in the Baltic see is the Polish M/S Jan Heweliusz, that was involved in a number of of accidents, until it finally capsized in hard weather.

The article says they fairly quickly tried to reduce speed once they noticed something was wrong. But due to a (UI?) mistake they only reduced speed for 1 engine. It wasn't until 3 minutes later they finally fixed that mistake but by then it was too late.

So they were unable to understand their own speed controls.

I’m sorry for bringing this up here, but why do I need to scroll sideways in Safari on iphone on Hacker News every time there is a quote written in an unproportional font? Just, why?

Because he used block quote syntax. It's designed for code on HN's implementation, so it preserves newlines, instead making you scroll.

It's a poor choice for quoting non computer languages.

People wouldn't use it if a better option was available. Lots of people are familiar with Markdown, which lets you start a line with > to have it quoted, but HN does nothing with this syntax so it looks ugly and as a consequence people don't do it.

I use asterisks around quoted text, which renders it in italics, but does not disturb line wrapping.

I at least use the '>' for human language quotes anyway. It's better than block quote, and it's pretty common syntax from email list serves.

More importantly, in mobile the code block's width is only 200 pixels.

Seriously this. Not wrapping text doesn't also mean fixed width 200px viewport.

The problem isn't "because they used codeblock" the problem is codeblock is broken.

Does anyone know a HN web interface (like hckrnews.com) that prettifies such quirks on the comment page for mobile phones?

https://app.hackerwebapp.com is rather nice, although read-only. Tapping a link if you want to comment is acceptable to me, though I'd love to have voting on there.

Because the markup for those blocks isn't intended for general-purpose quotations; it's <code> blocks. You don't word-wrap code.

Pretty sure merely not wrapping doesn't imply quite as horrible a UI as we have there.

Leave it to HN to uncover the real cause.

I completely agree, it seems like the speed was entirely excessive, and they literally lost control of their boat. Shameful.

This sounds like pandemonium and panic. Sounds like the bridge was totally out of control. They didn't even follow basic procedure to warn nearby ships of danger, they just plowed right in front of one.

When will the first ship crash because of a BSOD? You think I am joking? No, unfortunately several types run on general purpose OS, and the possibility is there.


> The USS McCain was traveling at over 20 knots at the time of the collision


Sorry. That does not compute. Based on that visual, the ship was dead in the water.


The McCain entered the TSS at 20 knots and varied between 20 and 18 knots until the steering problem began. The OOD ordered the vessel slowed to 5 knots but due to confusion on the bridge the orders weren't carried out properly and the vessel was still making 11.8 knots and turning to port at the moment of impact. The Fitzgerald was also traveling through traffic at 20 knots and narrowly passed three vessels at that speed before finally being struck by the Crystal.

Sounds like some kind of cowboy culture. "Hey, we have this fast and maneuverable ship moving along these lumbering civilians. We can handle it, we're the best of the best!".

A bit like those organ donors, err.. motorcycle drivers, that swerve among the traffic at high speed.

This to me is the under reported fact. Realizing how fast these ships were moving up to and through the moment of impact, while the crew responded hopelessly is extraordinary. Absolutely tragic.

Sure, don't believe your lying eyes. Point out a single scratch that indicates anything other thana 90 degree impact with a stationary vessel.

If you read the report that is linked above, you can see the relative speeds, headings and impact geometry.

The McCain crossed in front of the cargo vessel and was hit in the aft section by the cargo vessel that had a constant speed and heading.

You don't stop or turn a cargo vessel as quickly as the McCain can maneuver. You also need to take into account that you don't shove a ship sideways through the water easily - it can't slide as easily as a car can. The majority of the cargo vessel's kinetic energy will go into plastic deformation. It's not a sudden impact, more a crushing and deforming.

Edit: I have to revise what I said about the impact, according to the report, sailors close to the impact likened it to an explosion.

When a car gets t-boned at an intersection, do you always assume it was stationary? Please point out what aspects of the damage has speedometer-like qualities that your eyes are seeing.

There will be, by physical necessity, surface damage reflecting the forward motion of the penetrated vessel.


There is no visile damage indicating that the penetrated vessel was moving forward. The damage is perfectly symmetric, as you can clearly see.

It's not just boats that have safety-critical UI design problems. The avionics in airplanes are becoming so complicated that managing the avionics is almost more difficult than flying the plane.

I'm a private pilot who has been flying a Cirrus SR22 for twelve years. In that time it has gone through two major glass cockpit avionics revisions. In the first revision, called the Avidyne, the autopilot was either on or off. In the current revision, called the G-1000, the autopilot can operate in two modes: AP mode, where the autopilot is actually flying the plane, and FD or flight-director mode, where the autopilot does all of the calculations to figure out where the plane should be flying and displays a target on the primary flight display, but the actual control of the plane is still in the hands of the pilot.

If the plane is stable, it is very easy to get fooled into thinking the autopilot is flying the plane when in fact it is not. There are only two visual indicators that tell you if the autopilot is actually flying the plane: a small green LED on the autopilot console, which is down near your right knee, and another small annunciator on the primary flight display. It looks like this:


The autopilot indicator is indicating AP mode in that image. See if you can spot it.

It has happened to me more than once that I thought I had the autopilot engaged when in fact I had only turned on the flight director. I predict that one of these days someone will die because they made this mistake in instrument conditions.

Air France 477 was caused by UI stupidity, too.

Linked controls (nobody realized the junior copilot was making opposing inputs, which were then averaged with the pilot's) plus poor autopilot UI that they were accustomed to ignoring, made it stall and crash after a single wind speed sensor iced up.

If nobody had touched the controls, autopilot would have flown safely through the storm.


That's a very simplistic interpretation. The article is really worth a read.

The whole accident is a prime example for a very minor problem (loosing air speed indicators) spinning completely out of control, with the crew being making every possible mistake all the way down, all three people in the cockpit completely ignoring 47 stall warnings.

Losing airspeed indicators can be a minor problem, but not in a jet at altitude at night, which was the case for AF477. You can fly a small plane without an ASI, particular in visual conditions, because the margin for error is large and you have other visual and auditory cues to tell you whether you're in the ballpark. But Jets at altitude fly in a very narrow envelope between stalling and over-stressing the airframe (look up "coffin corner"), and in instrument conditions you have no way to tell whether you're in the zone or not. Furthermore, without reliable airpseed, the autopilot stops working properly. AF477 was not just a case of the crew being stupid or bad UI. It really was a very serious situation aerodynamically.

Agreed, I was just paraphrasing from old memory. Only intended to get people interested in further reading. :)

nice! Also an SR22 pilot (though I just sold mine a few months ago).

Here are some other G1000 confusions I remember:

- Flying down the ILS expecting to click the "go around" button on the throttle and see the missed approach cycle .... only to find out that the autopilot didn't know I started the approach because I had the wrong leg selected as "active" when I across the IAF (and I've been tracking the green ILS instead of the PINK gps for the approach)

- Given "vectors to final" from ATC, selecting "vectors to final" on the MFD, and then have ATC issue a speed restriction up to some waypoint ... which has now just disappeared because "vectors to final" doesn't display any of the waypoints (I think the logic is that you shouldn't need them, except in this case when you do)

- Doing an approach that has a IAF and IF with a holding pattern. Am I starting the approach from the IAF (in which case I do the hold), or from the IF (in which case I proceed directly to the FAF)? Once I've coordinated that with ATC .... I forgot to tell the autopilot who helpfully started planning for the holding pattern.

Honestly I think the solution here is more automation not less. These systems got so bad because pilots correct for them all the time.

Wow that UI is truly terrible. It's like they said "we need all this information on the screen" and then just dumped it anywhere. Who knew Microsoft Flight Simulator 2.0 was so accurate?

MSFS is amazing. So is X-plane. The latter has aerodynamic models accurate enough to simulate flight on other planets!


Is there a purpose to the display being so colorful? If AP were the only green thing and the others were monochrome it would stand out more.

Most of the colors on that display have a rationale. For example, on the speed tape on the left, the white, green, and yellow colors all map to colors of a standard airspeed indicator. That the course (CRS) is green instantly tells me I'm navigating by a ground-based VOR, not GPS (which would be magenta). Same with the green diamond on the right by the altitude indicator. The waypoints at the top are all GPS-calculated, therefore also magenta. At the top, the green radio frequency is the one you'll transmit on. The blue airport icons in the Nearest page (bottom left) indicate towered airports (matching those found on standard aeronautical charts).

(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)

Do you have any opinion on the G1000 (and subsequent Garmin flight decks) vs competitors, such as Avidyne Entegra?

My feeling has always been that the Garmin UI was somewhat clunky and suboptimal, possibly because they tried to keep it similar to the UI of previous smaller devices (such as the GNS 430); a bit like if the iPhone hadn't come along and we'd still scroll by putting our finger on a little arrow in a scroll bar on mobile devices.

My impression was that other manufacturers had a better UI, but somehow didn't make it in the marketplace.

I'm not familiar with the Entegra. I've played with stuff by Dynon and Advanced Flight Systems though. If you think the G1000 is clunky, try the Advanced system. I'm really not a fan. Perhaps it's for that exact reason (that Garmin products all work somewhat similarly), but I've been up in a friend's RV-10 with the Advanced system in it, and I find it to be much more clunky.

The GTN650 keeps a bit of the GNS430 feel... and those are, in my opinion, the best parts. I hate scrolling through the alphabet by dragging my finger across the screen. I have a similar disdain for trying to select stuff in-flight on my iPad in ForeFlight.

I think there's some truth to your GNS 530 theory... Pilots are not typically that interested in stylish/modern UIs, and they're not thrilled when a familiar UI changes. There are so many features now that it's a challenge to find room on the PFD. I'm curious, which other UIs do you prefer? What do you think of the G1000 NXi?

> which other UIs do you prefer

Well, I haven't flown other glass cockpits. I just find the G1000 clunky and a bit unintuitive, that's why I was wondering whether there are still viable and possibly better competitors out there.

yes, thanks for your reply. It's why I asked my question that way (Chesteron's fence etc).

Would it be possible to display that same information using a traffic light system?

(Red=Immediate action required, Yellow=keep an eye on this, Green decaying to grey=something that changed (eg AP OFF green then turns gray after 10 seconds or so). It would need to be applied with discipline to avoid every single piece of information being red and hence useless. (cf phone notifications or people who click OK to every dialog box).

Information overload / fatigue is a real thing and something designers need to concentrate on more, the ugly brother of "minimalism" which looks pretty but is frustratingly useless.

A little late getting back to this (was away from HN this weekend), but some things do use color changes and background changes to alert the user. There's also audio tones for various things, like the autopilot being disabled (regardless of whether the computer or user disabled it). The actual sounds depend on the features installed; a GFC700 autopilot has different sounds and alerts than a KAP140.

If you're interested in human factors in aviation, there's a lot of work being done out there in the field. A friend of mine is actually working on an MS in Human Factors at ERAU.

I'm impressed. But how did you figure all that out in the first place?

RTM and training.

Yep. I did both my primary flight training and instrument rating in a G1000-equipped aircraft so it’s like learning a powerful IDE - just start with the basics and keep adding on.

The colours have significance. There's a famous talk by a AA training captain, Capt. Warren VanderBurgh, about the dangers of over reliance on automation, and it's called "Children of the Magenta" (magenta being the colour with which the computer generated navigation guidance is displayed).



While the "AP" indicator is very important, such that overlooking it, or rather missing its absence, could lead to loss of control and death, the same holds for many other of the items displayed.

That's actually a great point: "missing an absence" is far harder than "noting a presence of opposite indicator".

> the same holds for many other of the items displayed

Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.

I didn't (and wouldn't necessarily) claim the same ratio.

But clearly airspeed is critically important, attitude is, a wrong heading can kill you (eg Varig 254 [0]), a transponder that's off can kill you (eg the Embraer/GOL accident [1]), wrong altitude can clearly kill you, etc.

But you've got a point, it's a pretty small indicator for a pretty crucial function. However, making everything else monochrome doesn't strike me as a realistic or preferable alternative.

[0] https://en.wikipedia.org/wiki/Varig_Flight_254

[1] https://en.wikipedia.org/wiki/Gol_Transportes_Aéreos_Flight_...

> airspeed is critically important, attitude is, a wrong heading can kill you

Losing track of airspeed/attitude/heading is a whole different category of error than losing track of which mode the autopilot is in.

> a transponder that's off can kill you

Not without a whole pile of other errors stacked on top of that one.

Some of the colors do have a rationale. The blue and brown background are actually the attitude indicator display. Blue is sky. Brown is ground. There is now an option available that renders the terrain you're over so you can "see" outside via the PFD even in clouds, e.g.:


But the other colors I think are just "because they can." There are a lot of IMHO stupid aspects of the G1000 UI design. (To be fair, the G1000 has to many features that designing a good UI for it is a real challenge.)

"managing the avionics is almost more difficult than flying the plane" The same goes for modern cars. The electronics is a nightmare. HVAC controls locked away behind touch screens menus. It's awful.

Oh, so much this! The whole UI world seems to have jumped the shark about 2-3 years ago. I dread the day when my current car (a 2012 model) dies because everything on the market today sucks UI beans. (Actually, the same goes for phones and laptops too. I have an iPhone 4S running a jailbroken iOS 7 and a late 2013 Macbook Pro Retina running Mavericks, both of which I am going to hang on to until either they or I die.)

Militaries are good at making horrible UI. :-) I used to work at early warning radar, that should notify our tops about incoming ICBMs. When there's a target, classified as "suspicious" or "something that's going to fall onto {our, neighbour} territory", the following happens: - very loud sine 1200Hz tone starts sounding - the only output device, "fast-printing device", starts dumping hexdumps of internal structures to long 10cm wide paper (like toilet paper). - the whole chain of command start yelling to each other (downwards), demanding data and info about the target.

So as the last person in that food chain, you're in the middle of panic, 1200Hz are drilling into your brain, damned thing prints hexdumps, and you need to apply binary shifts and ANDs, convert from floating point hex to decimals and pray that there's enough paper in damned FPD.

I could never imagine worse UI, it's strange that we didn't start WW3 in those conditions.

"Militaries are good at making horrible UI."

This is extremely applicable: https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa...

Disclaimer: it's an article I wrote about why government software contractors suck at their jobs.

A key occurrence during this mishap:

0127 The Officer of the Deck ordered course to the right to course 240T, but rescinded the order within a minute. Instead, the Officer of the Deck ordered an increase to full speed and a rapid turn to the left (port). These orders were not carried out.

0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took over the helm and executed the orders.

I've witnessed multiple similar situations on a warship (imminent loss of extremely critical systems), and had to forcibly push the watchstanders out of the way to do their job for them. Many people are going to freeze when the SHTF, and there may be no prior indication.

Major attaboy to the BMOW who saved many of his shipmates. Given the incident angle of collision, many more would have died from a perpendicular collision.

Yep, but that freeze is limited with more training, and mixed watches when teh newbs have to be rotated in for the real thing so the "hold my beer" guys aren't outnumbered 10 to 1 by the frozen folks.

I can't believe these watchstanders had the LOK they should have had on the steering system, or every one involved in ship control would have been able to immediately identify the problem and realign the steering system, other than bmow.

I don't think the senior watch team had their st either, or the orders to prepare to take manual control of the steering and propulsion system aft would have immediately been out.

Also it makes little sense that lookouts who calculated cpa at collision weren't raising the alarm. These guys who I had to do their job for them: I got them removed, and tried to get them off our boat. They were fine people but they were a danger to us.

Yeah, it's boggling how it went down. That's why I can't credit "UI" a cause, not at all. I'm no seaman, but I have some close contacts. UI might cover a BM taking a second before he realized the controls weren't ganged. Maybe.

UI doesn't cover mass confusion -> panic over critical loss of control that had NOT been lost. They heard hoofbeats and decided it was zebras, not horses.

There's a lot of acronyms in there.

LOK = Level of knowledge?

BMOW = Boatswain's Mate Of the Watch

ST = ? Not "Subject to" or "Such that" as I've seen.

CPA = Collision Prevention Assist in automotive systems, but maybe not here?

ST = shit together

CPA = closest point of approach.

CPA is calculated for anything close ahead of time, but only if both you and another ship are moving in a straight line. Which the McCain wasn't.

I don't know which one is more bizzare here - the story itself, or the barrage of "this is due to bad UX" comments in this thread.

So I guess if this warship fired all its rockets away, "due to bad UX", and destroyed a small nation, I guess the comments would also be about a bad UX. Oh crumbs, the "check status" button was so close to the "start armageddon" button. Perhaps we should submit a meek complaint to Microsoft or something.

"Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control.""

So... we gave the control of a warship to some guy that... has some difficulty navigating through the straits that like 1M of ships go through every day, without problems. Mind you, this is the navy that is supposed to be highly trained to deal with real-world issues such as naval blockades, pirates, and even wars.

It does not make sense at all. Allegedly there were some cuts to funding for navy. Maybe someone is trying to make a point. I do not know, this is just unexplainable. Certainly nothing to do with just "bad UX"

The problem is that you can't "fix" humans. They'll make mistakes. Aviation is as safe as it is precisely because it moved past the "pilot error! that guy just made a mistake, how can one be so stupid" attitude evinced in your comment.

You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.

Good UI makes the effort of doing the 'right thing' very little, and the effort of doing the 'bad thing' as costly as possible.

Design (in my opinion) is planning out what good and bad things are for a given tool and determining how to express that through the UI.

> Design (in my opinion) is planning out what good and bad things are for a given tool and determining how to express that through the UI.

I disagree with the premise you have that the designer deciding what is good and bad is the whole or even the right story. I think I might agree with the implication that a system should make doing cognitively difficult/safety critical things easy but there is no possible way to plan for all eventualities, that's why we have 'intelligent' controllers in ultimate charge.

One day we might have artificial intelligence in charge but we're not there yet.

So instead of the goal of good UX being the designer planning out what is good and bad, it is much better to design a system that reduces cognitive load but presents information about the current state of the system in the most obvious and intuitive way possible. It should do everything it can to make sure the operator understands the current state of the system.

In terms of operating complex physical systems like ships and aircraft the ultimate goal of designing control systems is to simultaneously take as much of the burden off the operator as possible but present all information needed in order to bring the system back to an _understood_ state as rapidly as possible following deviation from that state. This is the only way to maintain _control_.

It's reasonable to try and make it difficult to get to a state that is 'uncontrolled'. But it's imperative that more credence is given to getting a system back to an understood state once the controller finds them self in one that's not understood. It may get to this state in a way the designer didn't plan for, so getting out of it has to be incredibly quick and easy.

Personally, I put more stock in getting the system in an understood state than a controlled one as from there it's easier to return to control. Without understanding the state of the system it's easy to make further mistakes.

I think that's the real point. The ship in question is by far not the largest and should be more agile than most ships that go through these waters. How can ferries and tankers easily master this every day and the Navy is not? If they cannot figure out how to solve a situation like this within 2 minutes, how would they react to enemy fire or being attacked by another ship?

Seamanship in the USN has been on a downward slope for over a decade due to changes in training methodology. Qualification standards have slipped, and I'm sure that officers have slipped through the cracks who in previous generations would have had to recycle through the training programs. The 7th Fleet has huge issues right now.

Amazing that someone would design in multiple steering wheels, only one of which is active, and no big indicator to make it super-obvious which one it is.

Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.

> Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.

This is a fallback in case the primary rudder fails. You can still shift left or right, but you will take more time and it will be far less precise than using the rudder.

This is also valid for aircraft, where not only the rudder can be compensated but also the elevator (aka up/down) by simultaneously modifying the power of all engines. You can see a list at https://en.wikipedia.org/wiki/Flight_with_disabled_controls.

The UI issue being that ganged control should have been the default, but separate control was instead.

The difference being that aircraft throttles are not modal and are always 1 throttle = 1 engine.

Happens more often than we like.

I know of a ferry that a local warf built that had two bridges, and a combined throttle and rudder in each.

The thing is that when moving from one bridge to the other, the crew had to flip a switch to indicate what direction was forward. And quite often they forgot.

End result was a long history of damaged because ferry would ram the pier when the crew was actually attempting to move away from it.

That is super dumb and dangerous. They should just flip the inputs on one end.

EDIT (since some people obviously don’t understand the problem): ... so that each set of controls is always correct for the respective side on which it is located. No switch is necessary.

Even better, make the stations operable from either side. Then the yokes always orient in reality, and it's just the frame of reference of the pilot that changes.

Eg, if you're facing the dock, and push forward, you'll hit the dock. Take the other side and point your body to sea. Intuitive.

No, they just have a big button by each wheel marked "MAKE THIS THE BOW".

When would you ever not press that button?

You’re bikeshedding on a switch versus a button, still an extra, unnecessary step to forget. Same problem. You failed. Try again.

Check out the recent O'Reilly book Tragic Design for more situations exactly like this.

Poor UI design is remarkably common, even on controls that are essential for safe operations.


Also the classic Field Guide to Understanding Human Error.

Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error...

Older PDF (paperback is well worth it, in my opinion): http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...

In my view, on screen UI instead of physical controls is a big factor. If the throttles had been levers it would be instantly discernable if one or both were being moved. This is also why I dislike touch screen controls in cars. I want levers and knobs that give tactile, physical feedback.

Agreed on this. The more important controls should be operable by a suited astronaut, and should also try to express the current 'feedback' of the system state.

Decent odds you've flown on an airplane with a similar UX for primary flight controls.

Airbus uses two "side stick" controllers that are on opposite sides of the cockpit. This was a contributing factor in the Air France 447 crash.

> > Amazing that someone would design in multiple steering wheels, only one of which is active, and no big indicator to make it super-obvious which one it is.

> Decent odds you've flown on an airplane with a similar UX for primary flight controls.

Ah, well Airbus does a few things. 1.) A "dual input" warning is issued if there is an attempt at using both controls simultaneously. 2.) There are lights to indicate when your sidestick is active and when it is not.

I believe the warning can change depending on which of the 3 flight modes the aircraft is in at the time. Big contribution to AF447's demise was that the aircraft was in 'alternate flight' mode and the crew assumed it was still in 'normal flight' mode and made a lot of their judgement calls accordingly.

For an industry that is so safety conscious, I believe this is a huge flaw in disaster control. To put it in context that most readers here can understand - lets say your everyday computer uses OS X as its operating system, but one day, with deadlines to meet, you have a huge crash, and the OS reverts to Windows, and you have to find the problem and remember the appropriate commands under intense pressure...

I'd argue it's more like getting dropped into single user mode. No friendly GUI, but the underlying systems are the same. The flaw with any sort of safety net is that you get used to it and forget the basics of aviation.

The big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane. He overcorrected in reaction to turbulence and the rest is history. Normal law does not allow the pilot to set an angle of attack that would lead to a stall. In the alternate law modes this protection is not there and so when the PIC didn't adhere to the rule of "don't pull up while in a stall" there was no safety net to prevent him from exacerbating the situation. In fact he kept pulling back when the stall alarm went off.

A better UI would not have solved the self-inflicted problems. From the findings sections in the wiki entry:

- The pilots apparently did not notice that the aircraft had reached its maximum permissible altitude

- The pilots did not read out the available data (vertical velocity, altitude, etc.)

- the crew made inappropriate control inputs that destabilized the flight path;

- the crew failed to follow appropriate procedure for loss of displayed airspeed information;

- the crew lacked understanding of the approach to stall

- the crew lacked practical training in manually handling the aircraft both at high altitude and in the event of anomalies of speed indication

- the two co-pilots' task sharing was weakened both by incomprehension of the situation at the time of autopilot disconnection, and by poor management of the "startle effect", leaving them in an emotionally charged situation

- the crew did not respond to the stall warning

A better cockpit may have given the pilots a better chance of surviving but definitely wouldn't have guaranteed a better outcome. One only needs to look at Asiana to see that even Boeing, with their contrasting approach to UX, can't save pilots who lack basic airmanship. My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.

Conversely, one only need to look at Qantas' QF32 incident to see that good airmanship can absolutely make catastrophic failure survivable. Yes, there is a lot of information to process in an emergency... but the Qantas crew took that information and delegated appropriately. The Air France pilots lost their cool and fucked up.

> The big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane.

The pilot flying wasn't the pilot-in-command. Half the problem was the PIC was out of the cockpit at the time and the lack of any clear command structure between the two first officers in the cockpit. You can also argue that it may have been recoverable if the PIC took over as PF when he returned to the cockpit (had he acted rationally, etc.), instead of being confused by the situation they were in and unable to get out of, likely without knowing what the PF was doing.

> My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.

Much flying nowadays is through RVSM (reduced vertical separation minima) airspace, and you're not allowed to hand-fly the aircraft there (in general, modern autopilots can maintain altitude better than a pilot can).

"PIC", pilot in control, refers to the pilot actually flying the plane. Not the command or seniority structure amongst pilots.

There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.

PIC is in command, not in control. In plenty of short-haul flights, the FO can be PF, but they aren't competent to be PIC.

See also <https://aviation.stackexchange.com/questions/33414/who-is-th....

As in the AF447 case, the PIC will delegate to an acting PIC while they are on their rest break, but ultimate responsibility still remains with them.

My error. I was getting confused on the BAE terminology:

PF Pilot Flying

PNF Pilot Not Flying


Good points all around. Obviously it's up to the human beings to do the best they can in the face of limited information and control.

But where does your viewpoint meet up with someone like Chesley Sullenberger who says the pilots would have probably not crashed if the plane was a Boeing rather than an Airbus, because it would have had an angle-of-attack indicator?

QF32 had 5 (!) rated pilots in the cockpit and managed to communicate and delegate effectively. That's truly an amazing accomplishment.

Right, I was thinking of making the same point.

The initially-designated co-pilot also was virtually fully occupied simply clearing alerts from the aircraft's control and diagnostics systems -- for about 45 minutes as I recall.

That's a near-deadly case of TMI, I suspect.

And as the Air France 447 cockpit voice recordings demonstrated, those are not sufficiently obvious in all circumstances (particularly in high stress situations when you're already several steps down the path to disaster).

Redundant affordances are needed:

Controls that are active should be illuminated in a particular color, say red.

Controls that are disabled should be extinguished, physically-locked or track active controls, and sound a warning when manipulated.

I can imagine the requirements doc that led to that, where some Pentagon wonk was thinking "What happens if the helmsman is shot? If there's engine damage? If the helmsman is shot and there's engine damage?" and wrote all of those cases in, and completely forgot about the case where the bridge crew gets super confused because they triggered an edge case in the software and have no idea how to regain control of the ship.

Well, it's a warship. In their defense, they really have to plan for people dying and part of the ship being destroyed.

But if it leads to them not being able to steer through a busy area in peacetime where thousands of ships go through every day (many larger than this destroyer), this clearly failed. With this happening I'm not sure if they would've reacted better if they had suddenly been under enemy attack. Would they've been less confused then?

Having differential engine control isn't too surprising - it's just another way to maintain a course in addition to the rudder.

Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.

Airliners usually have a hardware clip to 'gangload' all throttles together, and the 'interface' of having two or more separate levers next to each other makes it obvious if you missed one while moving them, or notice that the clip is flipped so the levers now work independently instead of all as one.

Then again, in high stress situations even totally obvious signs like this can be missed, as evidenced by the Qantas 747 crew on the famous runway overrun in Thailand some years ago. I believe in that case, a large contributing factor was when the captain went to pull the levers back over the rear detents for reverse thrust after landing on the wet runway, he only grabbed three of the levers, and left one engine running at just over idle speed.

Everyone in the chain of command in 7th fleet (from ADM Smith on down through the captains and those standing watch) should have been separated and potentially prosecuted for negligence. UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals, and obviously many systems failed for this to happen. When the military runs well, it runs on accountability -- there's been a serious shortage of that, especially above O-6, for a long time.

"Retiring" without losing rank doesn't cut it.

> UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals

There are plenty of examples of "UI confusion" causing professionals to make mistakes in all sorts of industries. I'd suggest taking a look at the book "Behind Human Error," for example.

http://www.usabilityfirst.com/glossary/mode-error/index.html https://www.amazon.com/Behind-Human-Error-David-Woods/dp/075...

From what I hear the Navy has been very diligent about accountability. There are problems you can't really hard-ass yourself out of.

Multiple crewman have died from multiple preventable errors in multiple incidents. I haven't heard about any firing squads for COs? Normally we Americans are so enthusiastic about severe penalties? Watch-keeping and safe navigation are boring, so officers need extra incentive to pay attention to them!

"Preventable" doesn't mean "preventable by harsher discipline".

Haha this has got to be a reference to theWarOnDrugs...

Not intentionally. But now that you mention it...

Actual naval experts in HN notwithstanding, I think it's worth remembering that a little knowledge, at times, can be a dangerous thing. This is true of many topics on HN that are only obliquely related to software engineering. Silicon Valley has earned a great deal of confidence by disrupting other industries by out-thinking their experts, but perhaps we should temper that confidence a little, least it becomes hubris...

Bottom line, if we're going to dismiss experts, I think we should be armed with a little more than the knowledge we garnered from an internet article.

Applications are open for YC Summer 2021

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