Earlier quoted context omitted.
Therac-25 comes to mind...
Therac-25 was at least more deadly. Also much more complex than a UX failure.
Certainly there were several intersecting issues there, but UX was a significant one.
Citi Missed a Fat Finger
31–40 of 92 posts
Re: Citi Missed a Fat Finger
#32> However, as data from that external feed was unavailable, the price of the value of the Index instead defaulted to -1 To me, this reeks of a couple of bad experiences I had repeatedly as a back end developer coordinating with the front end: 1. Demanding that my services always returned correct-looking data, even if it wasn’t available, because they couldn’t (or wouldn’t) handle errors. The story always went like th…
> if a service returned a 4xx, it would trigger an exception in their front end code, and they didn’t want to tackle the complexity of handling potential errors from a bunch of different back end services
I’ve seen this when the frontend team is building a fat client/smart client/Single Page App but they really want to be building a thin client/dumb client/server-rendered app. Basically it’s a technological mismatch, and client teams feel a lot of pressure to build an SPA but don’t like/want/need the extra compexity that comes with it.
Re: Citi Missed a Fat Finger
#33> However, as data from that external feed was unavailable, the price of the value of the Index instead defaulted to -1 To me, this reeks of a couple of bad experiences I had repeatedly as a back end developer coordinating with the front end: 1. Demanding that my services always returned correct-looking data, even if it wasn’t available, because they couldn’t (or wouldn’t) handle errors. The story always went like th…
> Demanding that my services always returned correct-looking data, even if it wasn’t available
Ah yes, the age old "special values will signal an error, so we don't have to deal with error handling" approach. Which is always either a pitch for reinventing error handling in novel and ad hoc ways (usually bad), or for disregarding error handling altogether (always bad, sometimes entertaining).
Re: Citi Missed a Fat Finger
#34Earlier quoted context omitted.
Japanese uses different "groups" of powers of ten, maybe that tripped him up? 1; 10; 100; 1 x 1000; 10 x 1000 versus 1; 10; 100; 1000; 10000; 1 x 10000; 10 x 10000; 100 x 10000 https://en.wikipedia.org/wiki/Japanese_numerals#Large_number...
No, the gui input field das just 100000000000 vs 10000000000. Oops
So 2048 instead of 1024?
Re: Citi Missed a Fat Finger
#35Earlier quoted context omitted.
Probably. AI and LLM are pretty good at detecting extreme outliers and staying on the highly probable path.
You think the problem here is that the outlier wasn't detected?
If by "detected" we consider the E2E chain of humans and computers, then yes, that was the problem.
Re: Citi Missed a Fat Finger
#36> However, as data from that external feed was unavailable, the price of the value of the Index instead defaulted to -1 To me, this reeks of a couple of bad experiences I had repeatedly as a back end developer coordinating with the front end: 1. Demanding that my services always returned correct-looking data, even if it wasn’t available, because they couldn’t (or wouldn’t) handle errors. The story always went like th…
Maybe not as bad, but similar ... I've had a frontend dev say they needed to see designs from the designer before they could add any kind of error message or indicator. The status-quo is just silence, the page just stops doing anything. This is not unusual for various SPAs I've seen around the web. It is unfortunately a typical experience to click something ... no response? click again? wait how long? refresh? hello?…
That's often a problem with designers -- they only make a happy flow and only the end of it. No in-between states, don't understand the latency and errors exist, don't dig into boundary conditions and edge cases. It's a typical no-my-job-svg response to boot the problem upwards so their manager will make them aware of those pesky things.
Re: Citi Missed a Fat Finger
#37Report with rationale for the fines: https://www.fca.org.uk/publication/final-notices/citigroup-g...
Re: Citi Missed a Fat Finger
#38I've been in the room when it happened. In one memorable incident, a junior trader I sat opposite bought 100 bn Japanese Yen instead of 10 bn. His excuse? "I lost track of the zeros". We'd only hired the guy because he had a PhD and "PhD's are smart" - lol. In his defense the UI was awful. He left soon after...
Most of exchanges and brokers have a dialog window “Looks like unusual order with high price impact - do you really want to execute yes/no”
So definitely an UI issue.
Re: Citi Missed a Fat Finger
#39Earlier quoted context omitted.
This triggered a repressed memory. I was once on an ops team responsible for an application that had been turned over to us written in Java. The application ran in Tomcat, and prior to turning it over to us, the external vendor had "helpfully" built some monitoring and alerting for the application. One of the metrics they monitored was how many errors per minute and per hour were happening the application's logs. Whe…
"The errors let you know it's working; it's when the errors stop you have to worry."
For old cars we say say "If there ain't no oil under it, then there ain't no oil in it."
Re: Citi Missed a Fat Finger
#40> However, as data from that external feed was unavailable, the price of the value of the Index instead defaulted to -1 To me, this reeks of a couple of bad experiences I had repeatedly as a back end developer coordinating with the front end: 1. Demanding that my services always returned correct-looking data, even if it wasn’t available, because they couldn’t (or wouldn’t) handle errors. The story always went like th…
> Demanding that my services always returned correct-looking data, even if it wasn’t available Ah yes, the age old "special values will signal an error, so we don't have to deal with error handling" approach. Which is always either a pitch for reinventing error handling in novel and ad hoc ways (usually bad), or for disregarding error handling altogether (always bad, sometimes entertaining).
Spot on. Part of it is wanting errors-as-values without knowing what that is (which is good and contains a kernel of real insight), and part of it is assuming that error handling can be a negligible fraction of the work (which is the opposite of the truth and can only be achieved by doing a poor job of it.)