Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interesting to see this on HN. I currently work for the company that redesigned the HMI/UI following this incident. Or rather, it's how my company was founded. In the aftermath, the US Navy Command in San Diego contacted several UCSD professors in the Cognitive Science and Psychology department who specialized in high-impact decision making under stress and cognitive load. The Navy was apparently impressed with the detailed analysis and recs provided by these faculty and continued to collaborate with these folks on this an other projects. Eventually they were getting so much work from the Navy they founded a company focused on human factors engineering and interface design for complex systems.

The two original founders recently retired and our new CEO is a former Captain of the USS Zumwalt.



Any good reading on this? Might be some interesting learning opportunities for (cyber)security monitoring, which is a total mess right now. Stakes are a bit less severe, but still.


I would recommend Ed Hutchins' "Cognition in the Wild". He examines the performance of the crew of a ship acting as distributed intelligence and the many factors that go into making them an effective unit (or not).

Ed was also part of the UCSD Cognitive Science department at the time of the Vincennes incident and I suspect it was his work, along with Don Norman's, that drew the attention of the Navy. At the time, I was doing an undergraduate independent study in his lab, where we spent hours watching videos of airline pilots in 747 flight simulators, looking out for errors while using the flight guidance system. Our "textbook" was the operations manual for the 747 guidance and autopilot system.

An example of the sort of UI things we were looking for:

"Improvements" such as replacing the analog altimeter and airspeed indicators with digital readouts deprived pilots of operational awareness as they could no longer estimate rate of descent by watching the movement of the hands of the analog meters.

Anyway, here are the links:

This is the introduction and table of contents:

https://hci.ucsd.edu/hutchins/citw.html

Amazon link

https://www.amazon.com/Cognition-Wild-Bradford-Edwin-Hutchin...


I find the glass cockpit airspeed/altitude tapes to be significantly worse overall than analog dials. Not only is it easier to see rate of descent, but it's very easy to see whether the absolute number is where you want it to be. Normally if you're cruising, you will be at an even thousand or 500 foot increment. The big hand should either be pointing straight up or straight down. You can even see out of the corner of your eye if you're a little too high or low. On the tape you have to read a 4-5 digit number. Similar thing with airspeed. Once you are familiar with a plane, you know what angle the airspeed needle should be pointing for a particular phase of flight. It's much quicker cognitively to see the angle of a pointer than reading a number.


Overall, though, having flown both, I'd have to argue modern glass cockpits have significantly better UI than the old steam gauges. So many old aircraft didn't even give lip service to helping the aviator with a good instrument scan and just stuffed things willy-nilly.


I recall reading that Thrust II (running at 1000mph but somewhat closer to the ground) used analog meters so that a glance could get an approximate value and rate of change quickly and in a situation of heavy pilot vibration. I couldn't find the original article, but I found this breathless page from the manufacturer which alludes to this. https://masterhorologer.com/2014/05/03/rolex-unveils-two-bes...


>"Improvements" such as replacing the analog altimeter and airspeed indicators with digital readouts deprived pilots of operational awareness as they could no longer estimate rate of descent by watching the movement of the hands of the analog meters.

I find discoveries like this fascinating. The unconsidered knock on effects of decisions is one that is very difficult to appreciate at the time. Whether they were unconsidered because no effort was deemed necessary, just not enough experience by the decision makers to be aware the item was used for more than just the obvious use, or any other reasons besides any form of incompetence.

This is one of those times where not having enough people involved shows up. So it's a trade off on accepting a continuous rolling bit of changes just to make something happen now, or paralysis by analysis through committee of people to approve changes.


Loved his class at UCSD! It definitely was something that really sticks in your brain and never leaves cause of how unique the subject material and concepts were taught.

I wonder if they would update the theory of “distributed cognition” in an AI ChatGPT Turing complete world with ubiquitous computing. Thoughts?


Donald Norman's The Design of Everyday Things is a great intro to human factors and covers a number of high-stakes environments as well as more mundane things like door handles. Highly recommended reading.

https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things


Indeed a seminal work. Don is also at UCSD, and is a founder of the UCSD Design Lab.

https://designlab.ucsd.edu/


He retired (finally!) I believe. And indeed it is a seminal written work, User Centered Systems Design.. what a clever title!


I suggest you check out the work of Gary Klein and the Naturalistic Decision Making community, as the Vicennes work was one of the founding projects. He features it in his 1997 book _Sources of Power_.



Apologies for hijacking the conversation. Would you be able to recommend any reading specifically on complex UI for critical operations?


It's probably not what you are looking for but the DoD Design Criteria for Human Engineering are pretty good.


Fun fact the Captain of the Vincennes went to school for psychology and his father was a US Navy Psychologist in WW2.


From the wiki: “Rogers' next assignment was as commanding officer of the United States Navy Tactical Training Group at Naval Base Point Loma, a group responsible for training officers in handling combat situations.”

Is having that guy train people genius, or moronic?

https://en.m.wikipedia.org/wiki/William_C._Rogers_III


Arguably moronic, if as appears he disclaimed responsibility for the failure, and even criticized the captain and crew of the Sides for failing to replicate it. At the time of the incident, it appears he had driven his ship into Iranian territorial water, in violation of international maritime law, on an invalid pretext in violation of a direct order from fleet.

At least he was "passed over for promotion to flag rank", and retired three years later, at age 53. One wonders how much responsibility he admitted in his book, "Storm Center: A Personal Account of Tragedy & Terrorism". His wife might not have been exposed to the pipe bomb somebody put in his minivan just a year after the incident, had he demonstrated any contrition at the time.


Of course he was passed over for flag. At Commander and above, it's more or less expected that you have a successful Commanding Officer tour in rank order to promote. A few Commanders that don't get command make Captain, but it's the exception rather than the rule. And it's virtually unheard of to make flag without a successful Captain command, because there are so many more Captains than there are slots for Rear Admiral (Lower Half) that most end up retiring anyway. If your CO tour blows up in your face, it's basically a guarantee that you will be expected to retire at the earliest possible opportunity.

The best quote I've ever heard on the subject is "the Navy doesn't have hospitals for careers. It has leper colonies."


Commanding officers at shore training commands are mostly there work on their golf games and sign administrative paperwork. The real lessons come from people with not even half his experience. Even a former CO that allowed this to happen is probably better to teach basic tactics than a Lieutenant who has done maybe two sea tours, honestly.


Software engineers sometimes wonder about the importance of their jobs by comparing them to other engineering fields where mistakes can hurt or kill fellow human beings. And then there are jobs that hurt or kill regardless of the quality of your work.


Go read about the software bug that literally killed people by miscalculating the radiation dose given by a medical machine. There is software which can hurt or kill fellow human beings. Industrial controls, aircraft flight controls, the list goes on.


The number of people harmed by that ramshackle contraption never came anywhere near the number wiped out in just the one incident.

Mis-operation of the Aegis system is, BTW, also responsible for the sinking of a British warship, HMS Sheffield, in the Falklands war, with at least 87 killed. It failed to identify an Exocet missile fired by the Argentines as a threat, even though the Navy was thoroughly aware Argentina had them.. (Two other British ships were also hit by Exocets, one sunk, for a couple dozen more lives.)


Sheffield was not equipped with Aegis. The only ships in the 1980s that had it were the American Ticonderoga-class guided missile cruisers. Aegis is the name of a specific anti-air system based around the SPY-1 phased-array radar and SM-2 surface-to-air missile. It is not a catch-all term like Kleenex.


The anti-aircraft/missile defence on Sheffield was Sea Dart. The Argentinian pilots were familiar with the type 42 destroyer type and its radar, and practiced against the Argentine's own type 42s. This might have some bearing on their success as well.


Aegis is a particular system. Not a generic term for these systems. I don't believe UK ships used it.


> Mis-operation of the Aegis system is, BTW, also responsible for the sinking of a British warship, HMS Sheffield, in the Falklands war, with at least 87 killed. It failed to identify an Exocet missile fired by the Argentines as a threat, even though the Navy was thoroughly aware Argentina had them...

Attributing the failure to avoid the Exocets to "mis-operation of the aegis system" is pure speculation AFAIK, unless you have evidence that that was the cause?


I wonder what "jobs that hurt or kill regardless" you have in mind


* I'm stressed from working at a game studio --> but no one will die

* I'm stressed from working on avionics or medical software, or designing bridges/etc --> someone may die if I make a mistake

* I'm stressed from working as a firefighter or police officer --> someone (or myself) may die even if I don't make any mistakes


Thanks, doesn't sound like the same thing though. The text was:

"hurt or kill regardless"

which to me sounds like "someone always die" (not "may die"),

which isn't supposed to be the case when firefighters or police are working.


Anything to do with "defense" industry


Ok, depends on how you look at it. But almost always, yes


I'm not sure what you are implying. The nature of the work described above was to prevent a disaster like the shooting down of commercial Flight 655 from ever happening again.


Yes precisely, and (to GP) that's software and UX design. Not comparing with, it's that exact thing (in that case)


Nothing personal, just interesting to see how engineers think about how their work can harm other humans, yet some jobs are about creating machines or weapons meant for destruction.


In my previous job writing a naval combat system (not Aegis) I figured that I couldn't prevent warships from existing, but I could make the combat system better, safer, easier and less error-prone to use which would ultimately reduce the likelihood of people being killed inadvertently. But I totally respect people who choose not to work in defence.


Real software engineers care a lot, those with fake engineering titles after a bootcamp, not so much.


> our new CEO is a former Captain of the USS Zumwalt.

Wait! Wasn't the last captain of the Zumwalt called James Kirk?


I think your company is PSE, correct?


Indeed it is!

I'm fine with our name being mentioned. I didn't include it above because our website is trash, which doesn't bode well for a company with professional graphics designers and human factors engineers on staff haha.


The car of the best mechanic in town is usually drives a jalopy or the yard of the landscapers tends to be unkempt kind of a situation.


The cobbler's children have no shoes


The shoemaker's children have no feet.


I think if they wanted to name the company they would have done so in the comment


I, for one, am glad it was mentioned. There's nothing secret about it and it saves me some trouble. Thanks for taking one for the team, Guy who figured it out


Same here. With all the detail provided it’s not hard to figure out the company.

Btw. You can vouch for comments that are marked dead to revive them.


There have been only 5 "former Captain of the USS Zumwalt". That is a very small subset of humans. There have been more humans walking on the moon than former Captains of the USS Zumwalt.

Their names are a matter of public record and one can answer which works as a CEO with 5 simple google searches.

If they didn't want to name the company they shouldn't have identified it willingly and precisely.


Making clear allusions to the company without directly naming it allows anybody in this conversation who cares to figure it out easily, but doesn't get this discussion automatically indexed with that company's name. Naming the company in a response is rude and unnecessary.


Disagree. I sometimes have cause to comment here and obliquely reference my own project, without its name.

Because its name isn’t important to the context, and mentioning it seems gauche; I don’t want to ‘make the conversation about me’.

It’s not because I really don’t want anyone here to know about it: if that was the case, I would have kept my trap shut in the first place.


I don't want to know the company's name, but it's interesting to know the history of this event and how it came about.

If people want to do sleuthing, have fun.


Or at least frame it in a more passive tone like "would you be comfortable disclaiming the name of the company where you work?"


This is how every software UI should be designed as well.


Hopefully without people having to die first.


does the developer dying inside a little bit while making it count?




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

Search: