Citi Missed a Fat Finger
bloomberg.com
bloomberg.com
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 this: 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 had this one get escalated to management before, who fortunately supported me.
2. Resisting efforts to ensure that potentially dangerous values were displayed in attention-getting ways. Anything that didn’t look aesthetically harmonious was liable to get “fixed” without any consideration for why it was presented in a visually jarring way in the first place. As a back end engineer I sometimes lost this battle, since it was outside of my jurisdiction, but when I could, I looped in users or a product manager to help stop the madness.
Have the designer design it, sure, but until that happens, you have to show something for auth expired (tab suspended for a long while), connection failed (flaky wifi), or 5xx from service - as much as I may try to make that never happen, it is possible (database failover for a few seconds?), and the design can't just be "there shall be no errors", you can't decide that.
Source: was a memegeneer.
I Google'd "#FF00FF" to see how bad it was but was instead returned with a rather pleasant blue. Confused, I tried again. I got a completely different color. Same exact search. Different color. I've done the same, simple "#FF00FF" search and I'm up to five different colors with none of them being magenta.
How do you fuck something so simple as a HEX color code up?
(Hilarious story by the way. For a hot second when I saw the blue come up I thought maybe I was colorblind, too.)
Here's a color link so nobody else has to struggle: https://www.colorhexa.com/ff00ff
DDG showed the correct color fwiw.
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.
"Something went wrong". Sure, many or most users won't be helped by a specific error message, but they can use this message to ask someone how does. Especially if large tech companies just forget to offer support, a sensible error message is better than nothing. Sometimes error messages lead you down the wrong path if you don't know the intrinsics of an infrastructure, sure. But I still don't know which brain is responsible for the "guideline" to hide some essential from users. It is just objectively wrong.
It would be childs play to hide the "ugly information" in an extra menu, window, popup or anything. But doing UX isn't an excuse for bad engineering.
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).
Not just numbers. I worked on a ref dare system with minimal input validation. Copy/pastes would leave in white spaces, new lines, etc. This would then break trading which tried to execute them.
Aged 17/18 at a summer work program at a fund (~2000) I was given Excel and Bloomberg and had to calculate risk across client portfolios. Messed up the manual input of one by a zero resulting in the whole portfolio getting rebalanced, then un-rebalanced.
The same team passed off a trade via paper slip saying it’s yen. The person entering it didn’t recognize the yen currency symbol, assumed it was a 7 and traded the full number prefixed with 7 in yen instead.
Many many stories of many many errors.
For example, in one old FX trading system I know about you would type in the cross you wanted (eg say GBP if you wanted GBP/USD) and the amount and then if you hit enter it would execute. If you hit F5 it would execute that number of million of that cross. So say you wanted 10 million, you could type 10000000 and hit enter or you could just go 10 F5 and it would immediately execute 10 million. (ie if you hit F5 you didn't also need to press enter).
F6 was the same, but for billion. And yes it originally had an "are you sure?" chicken box but there was only one flag to disable all chicken boxes and one of the chicken boxes on another part of the system was such a constant pain in the ass that everyone had chicken boxes disabled. So if you fatfingered and hit F6 when you meant F5 you could literally execute a thousand times as much as you intended.
Other than massive wrong amounts, the other one I've seen a lot is people buying something when they thought they were selling and vice versa.
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...
So definitely an UI issue.
That's 10 000x. That one is, indeed, a UI issue.
Also much more complex than a UX failure.
In this case, if the value is unusually high say greater than 100 billion, make the trader type 100 billion before proceeding.
I confess that I also ignore popups and just click ok. This is where i appreciate github asking me to type the name of the repository, just to make sure that I know what I am doing.
Do people want a block? Every story about a bank blocking a transfer draws tons of outrage. It's my money, I can send it where I want, no questions, you can't stop me, how dare you.
I believe this is called an 'alert that cried wolf'.
It comes up everywhere:
- On-Call alerts received by my engineering team for our microservices that usually self-resolve result in the first action being taken by the engineers to be "just wait and see if it's a false alarm." We work to reduce the number alerts overall to reduce the noise.
- I'm reminded of "Cigna saves millions by having its doctors reject claims without reading them" https://news.ycombinator.com/item?id=35304017 In order to keep up with the claims, they just auto-rejected them to see if they were appealed in a way to filter out the "noise."
- We hear so much about Tesla's "FSD (Supervised)" and it's request that drivers "don't become complacent" but it happens anyway. After enough time behind the wheel with FSD enabled, we are swayed by the string of successes to become overly trusting of the tech.
> On Tuesday, the National Transportation Safety Board said that a crash last year on the Washington subway system that killed nine people had happened partly because train dispatchers had been ignoring 9,000 alarms per week. Air traffic controllers, nuclear plant operators, nurses in intensive-care units and others do the same.
The last time I was in hospital, I came out the next day and my ears were ringing for a couple of days from the _constant_ ringing of alarms.
My wife was in the hospital because she’d essentially stressed herself to the point of a heart arrhythmia. The irregular rhythm meant the equipment was basically useless at accurately determining her heart rate and the readings fluctuated wildly.
So what did she do for several hours? Laid in a bed anxious about the medical concerns, anxious about life, and listened to the monitoring equipment go off multiple times a minute as she crossed various alert thresholds, went back under them, crossed them again, repeat the entire time she was there.
I asked the staff to turn the alarms off or at least adjust the thresholds.
They just short of flat out said they wouldn’t because if they disabled or adjusted them and anything happened it would be on their head.
So my wife spent half a day being told to try and relax while the machine monitoring her heart and respiration and blood pressure constantly screamed at her that everything was wrong.
I've been involved in some systems that routinely spit out dozens of warnings per day. After 'fixing' some of them - maybe getting a system down to a few per week, bug reports started coming in that the system was 'broken'. Because people noticed the boxes and messages they routinely ignored were gone, and this must be a problem. Lots of re-education may need to happen on a large scale to actually 'fix' alarm fatigue across the board.
I tell them to do two things to tell them how to check system health.
1. Is it working normally? if so, then nothing is wrong.
2. Walk by the hardware once a week and check for idiot lights, check the system dashboard if one of the idiot lights is on. If no error is found, its a hardware problem (failed supply, drive, fan), if an error is found it's a failed server - either way, call us.
There are a handful of cases not fixed by this, but they're limited to time sync failures - which are critical, but generates no user facing alarms.
Several years went by... then because we finally had the time our ops team decided to audit and improve this application, including rewriting significant portions of its code as was pretty typical when we took over an application built by an external vendor. Long story short, we resolved almost all of the errors by the expediency of simply correctly interacting with the database behind the application instead of relying on whatever horrific dumpster fire output to the DB that Hibernate was doing. That's when things got super interesting, because the external vendor team that was receiving these monitoring alerts (unbeknownst to my team) had more than 100% turnover in the intervening period of time, having lost all knowledge about this, but suddenly starting getting a bunch of critical urgency alerts going off because the application was no longer emitting the amount of errors expected for the alarm thresholds. This ended up triggering a massive company-wide incident call, even though there was no external customer impact. I'm leaving a lot of details out, but let's just say it sucked up days of my life and was a massive waste of time for all of that.
Fun example of fixing something and causing an "issue" because behavior changed from expectations/baseline.
The better solution is to redesign / engineer systems which automatically solve the alarm condition so no person needs to know about the alarm. That usually requires many people to work together and requires far more complexity to solve, both initially and in ongoing upkeep.
"But the A/B tests show consumers prefer it!". Oh? So you have a degree in stats and experience running scientific tests? No? You're just a programmer who only knows how to enable the A/B test feature of your favorite javascript library?
Your A/B tests aren't testing what you think they are testing.
it's extremely hard to find the point where it becomes negative.
Think of it like emails, or texts, or calls: What's the exact number per day where you stop paying attention to them?
If someone dies because they ignored an alarm you did alarm, that's on them.
When something unexpected or out of the ordinary happens, what do you do about it?
- Nothing? Why did you do nothing? This was clearly a problem. This is your fault. - Figure out appropriate error handling? That’s hard work. - Just throw up an alert on everything and make it someone else’s job to sort through it all? Perfect, job done.
[1] https://99percentinvisible.org/episode/sound-and-health-hosp...
N = Length of string D
D = [0-9]+\.[0-9]+
C = 2 check digits using IBAN method against ND
It wouldn't help.
But the intent of what I suggested is to guard against many classes of errors including data entry, storage, transmission, and interpretation.
The only manual component is specifying the size. As to why the client isn't doing it, this order might have been placed over the phone. Or it may be part of a more-complicated strategy that required some finesse.