I don't even have anything to add. The paragraph speaks for itself... You can't make this up
ALL THREE PEOPLE INVOLVED IN THIS TASK WERE CONFUSED by the interface and all three thought that this was the correct way to do this.
This wasn't the case of one person checked the wrong box. Everyone who looked at this was confused. This problem was not individual, but systemic.
Unfortunately because of the court case, instead, people associated are the users.
These things were put together in haste in the 90's and Oracle keeps pushing them and their corporate customers keep these things going long past when the interface becomes utterly unfamiliar.
The blame has to be shared, however, with the battle-axe personalities of the people that use this stuff. They would like nothing more than to retire while still using the _exact_ same applications and dated interfaces they've used for 20+ years. Literally, these are default "grey-theme" java applications, with all kinds of inconsistent UI quirks and absolutely no shits given for discoverability or even being able to create hyperlinks so that people can share stuff without screenshots.
It's fine if it's the same people keep using these apps forever, but the problems start when new people get on-boarded. If it's like most places, the newbies will be given no training and the only help they will get would be from some dour in-house oracle-application jockey whose been doing the same thing for decades. That's when people make very, very expensive mistakes. We hear about this one because the sum was vast, but people make $10,000 mistakes on shit software from Oracle all the time-- that's partly why Oracle has a very deep bench of retained lawyers, I suppose.
I have to say Citibank deserves it.
I wound up going back several years later when I was thinking of a different field and they had that trashcan CUNYfirst system. By then the UI was already outdated and clunky. I wound up with the wrong class the first time around because of some issue and have to have it changed post payment which was time consuming. I would have rather used the IBM's.
It’s actually easy to sell shit software. The average person knows a lot more about cars, for example, thank they do software. I’m sure Oracle makes huge money on name alone. The IT manager doesn’t want to take a chance with some lesser name. Just get Oracle, then nobody can blame them when shit hits the fan.
Only incompetent people wouldn't blame the IT manager for choosing Oracle.
I used a class registration system that wasn't this and didn't mention a "shopping cart" metaphor anywhere, but the system was exactly the same. Why object to calling it a "shopping cart?
I can only imagine how hard it was to populate the available classes. I wouldn't be surprised if part of the huge administrative bloat in the various departments was people who's only job was to force data into and out of PeopleSoft.
There were a few dozen of us spread across the UW System who's sole job it was to extract and massage data from these databases... One, very large, central database that handled data for UW and every satellite college they had.
The answer is of course no.
The Oracle pitch is "We do this for Michigan State and can do X, Y and Z". That is true.
Oracle gets alot of shit for this stuff because they own the market for enterprise financial software. Their software is gross, they bought out the competition and generally suck, but that is what the market demands.
My uncle is a locomotive engineer. His railroad makes a conscious decision to remove any creature comforts from the cab, like a chair cushion. It's needlessly uncomfortable and is awful, but that doesn't mean that GE (or whomever) sucks. They delivered what they are asked to do.
The school cannot handle the requirements or implementation. Of course, but maybe a smaller, more focused provider than oracle can?
And yes, you have to be at peace with your data being god-know-where.
One of the setups I come to almost expect in maritime accident reports is an officer taking a night watch, alone, while somewhat fatigued. Warm, dark, quiet. After a few hours the ship has drifted significantly off its intended course. For unknown reasons (the officer was probably asleep) no attempt is made to correct... When they do wake up, they often don't have good situational awareness, and their focus is on pretending nothing is wrong, even if they are in fact already in serious trouble and need all the help they can get.
Night-time railway accidents are less common in my country, perhaps because the relevant unions insist on proper "if you're too tired just go home you aren't fired" type rules to reduce fatigue errors, but I do recall a case where a freight driver was dipping in and out of consciousness. When he was conscious he could see a red lamp out of the window, signalling "Danger" ahead so he'd reduce the traction power. If he'd been less sleepy he'd have noticed those red lamps were not getting closer each time, they were moving gradually away from him. His train was on a steep climb, and he'd reduced power so much it was gently rolling backwards. Oops. Nobody died, that time.
WTF are the administrators paid for if not that? Isn't that literally their whole job?
You can reference the Texas power outages. Just because the requirements were to fail in cold weather, doesn't mean it was a good choice
It's lazy UI but in some ways it's going to be more intuitive, not less, to any student who's ever used an online retailer before.
Oracle will audit them and find that someone accidentally enabled an extra, unused feature during an install one time. So, there goes another 10 million.
Actually the history of this app is a little more complicated. In the early 1990s, Citibank decided to establish an outsourced software development group in India to rewrite their banking software from scratch–they established it as a subsidiary company called iFlex. From 2005 onwards, Citibank progressively sold a majority of its stake in iFlex to Oracle, who then renamed the company Oracle Financial Services Software (OFSS). OFSS is listed on the Mumbai stock exchange, but Oracle owns the majority of its stock.
So, rather than being a product which Oracle developed themselves and sold to Citibank, this is actually in some ways the opposite – a product Citibank developed themselves and sold to Oracle.
I used to work for Oracle. I never worked on OFSS software directly, but I did work on an implementation project for some of it. I never saw the internal banking UI, all I ever saw was backend stuff – LDAP, BPML, JVMs, databases, load balancers, firewalls, etc. Indeed this article is the first time I've seen that particular UI in my life. But I can tell from the visual appearance that it is not one of Oracle's more recent UI development frameworks. (I don't know if this is because Citibank is running an older version, or if there are parts of the product still running on a legacy UI framework.)
Citibank developing in-house software then selling it to Oracle so that they can charge recurring licensing and support fees for eternity is incredibly short-sighted if you're Citibank or Manna from heaven if you're Oracle.
My guess though is the Citibank executives who signed off on this got promoted up and out of the department that has to budget for these licensing fees and support costs, and on both sides they received tidy bonuses for "increasing revenues".
Usually it's a win win, unless you value keeping control (which can be quite valuable)
My experience is that it's usually overvalued. An external, focused company will usually do a better job than an internal project. It's emotionally hard to give up control, but successful companies tend to focus on a few things, do them really well (areas of competitive advantage), and outsource everything else.
A best-of-breed external solution almost always beats an in-house solution.
I'd just never do something like this with Oracle. Their business model seems to consist of locking companies in, and then milking them.
Oracle paid Citibank over US$500 million for this company. There is no way a transaction that big isn't being approved by the CEO and board of directors of both firms. It wouldn't be under the control of the software licensing department. It would be controlled by the business development group in charge of M&As and divestments.
> Citibank developing in-house software then selling it to Oracle so that they can charge recurring licensing and support fees for eternity is incredibly short-sighted if you're Citibank or Manna from heaven if you're Oracle.
I have no internal info on the details of the Citibank-Oracle relationship (my role at Oracle was technical, not the kind of role where I would know that kind of business relationship stuff, and I never worked on the Citibank account either.) But, as @dagmx has already pointed out, I think it is highly likely due to the history of this software that Citibank has some kind of special licensing deal with Oracle which protects them against that sort of thing.
Maybe they saved the US$500 million they were paid for this software, and they can use it to cover the US$500 million it just cost them.
For Citibank that was US$500 million then, which they could either invest directly or return to investors. The opportunity cost of that cash has to be factored in.
It's also an a large ongoing liability to have a sizable in-house development effort when it's not your main business. Departments need to be staffed and run, business plans made etc.
For all of Oracle's flaws they're presumably going to have an incentive to improve the software, and more capital with which to do so from clients other than Citibank. For obvious reasons other banks would be more inclined to buy from Oracle than a direct competitor.
There's also often tax reasons for why it's preferable to buy a service v.s. maintain in-house software, and naïve back of the envelope math usually doesn't account for that.
This is the same ideology that led to companies outsourcing everything from facility management and cleaning services as the first victims to stuff as critical as IT operations.
Yes, it is a liability and likely also a higher cost (e.g. due to collective wage agreements) to do that stuff yourself. On the other side, you have the large liability of having no direct control over staff and work quality any more - you're entirely at the mercy of your contractors (who are incentivized to find not the best people, but the people willing to be paid the least).
This is important. Just a few days ago here on HN, there was a good discussion on how deliverables quality on seemingly "mundane" device chargers (in this example, one that was arguably for early Kindles) can vary wildly, while maintaining the same price point, with the sub-standard quality yielding more profits to the seller, and higher-quality units yielding less profits.
This is a impedance mismatch between what the buyer knows and values and what the seller knows and values. With a time slippage between the time the buyer makes a decision and when the buyer's organization figuring out the real ramifications. By the time an organization has outsourced enough to lose competency to not even know the impedance mismatch and time slippage exists or scope it if they're aware of its existence, sometimes they will find might be cheaper to in-source in the first place. My personal rule of thumb going in to evaluate these decisions is if the procedural complexity surrounding such software artifacts rises above a certain level, it is likely better to keep it in-house. Where that level is lays the art of business, it is largely experience-based.
When the 3D look became the norm for Windows apps, introduced by Office and, later, by Windows 3.1 (or 3.11), I used the DLL to 3D-fy my Windows app dialogs automagically. I also took some liberties with using Office graphic elements reasoning that a Windows or Office user would know the 3.5" floppy saves things.
However the OF technology is still supported by Oracle and while they themselves are trying to kill it, nobody is willing to migrate their core systems to something new.
Somebody requested that feature, and then someone discovered that if you hack around your system and set precise combination of fields, it will do the trick. So man hours were saved, some memo added to docs, and then the knowledge was lost.
And all of that instead of adding separate form for specific case. I've seen it more than once.
I once was deposed in a lawsuit regarding Oracle, and part of it was basically a UI issue. We had a paid customized interface that allowed users to upload basically a blob text or document (word, etc). When we went to UAT, we didn't see it in the UI in the app itself (peoplesoft):
Us: "Okay, we can upload stuff, where do we find it?"
Oracle: "Oh, that wasn't part of the project"
Us: "Yes it was, see spec #<insert #>."
Oracle: "... Well, it's in the database. A DBA can access it, so we met the spec."
Us: "That is not a rational interpretation of '... and users will access it within the application...' "
Oracle: "We're happy to build that customization for another <insert massive $$$ sum>"
This was only one of a few material issue that led to the lawsuit. We probably wouldn't have sued over it alone, which should give you a hint at just how bad some of the other problems were.
As an aside, the $/hour billed for customizations was $600, but the work was also outsourced to India. I asked a PM from Oracle how this was justified, and they gave a vague answer about multiple layers of management needed to oversee the developers. I pointed out that this price tag would allow for 3 managers per developer, with each person in the chain making ~$200k/year, and still allow Oracle $200/hour profit. I got a ¯\_(ツ)_/¯ response. That I have to blame on the organization & not Oracle though. I had the detailed ~500+ page RFP response & implementation plan, which specified 1,000 hours of custom work. But I didn't have the actual contract to see what additional work would cost. The organization either didn't negotiate that in advance (so their fault) or they knew in advance & agreed to it (also their fault)
Oracle as a product company (applies to all Enterprise Product companies) will not charge separately for a customization.
In any case, these were from the the actual consulting arm of Oracle inc. And IIRC, our Associate VP for IT said we shouldn't use both Oracle & Oracle Consulting, but that person was overruled by the VP for IT. I the VP was kept around until the lawsuit settled because it might have been taken as a sign or admission of culpability to fire the VP before that, but shortly after the settlement (which we won, incidentally) that person moved on for "other opportunities".
Things are a little better these days where you can often find apps (usually SaaS) that fill a specific need very well, but then you're usually stuck managing a dozen different products and a massively more difficult integration between all of them.
If you're using Oracle to power a home-grown system though, yeah: With a little effort you can swap the backend for something where the vendor won't show up with a surprise multi-$million invoice along with pre-made lawsuit papers if you don't sign it.
What really happens is entirely different. Oracle takes the request, foots the bill for an army of contractors to build it, if they haven’t already, and pass it off as we had it the whole time, just like we said.
Then up charge. Shake down street. Lock in.
I’m sure not all of Oracle operates this way, but that’s been my experience.
Homegrown systems are an easy low-hanging fruit to cost reduction.
Software to tackle the BPaaS on top of an Oracle add-on service, requires a pitch deck.
That must be what happened in my case! I didn't realize it was a standard practice. A large part of the lawsuit revolved around functionality the RFP required, Oracle said they had, and that Oracle even showed in what may have been faked screenshots during our review of vendors. Only in our case, the army of developers never actually finished it and Oracle came back to us with another massive bill to complete the project.
I'm not sure I've ever heard someone who's worked with Oracle who didn't have a bad experience. But if you have and you're reading this, just drop a quick comment to say "yeah, they were okay"
There was a complaining faction in my org, mostly disgruntled hold-outs from before my tenure. Whatever complaint they thought they had, I could bring it to our account manager, and it was pretty easy to see the root of the problem came from personal issues in staff, and insecurity with changing to better technology that they were not experts in.
Now that I've got mostly oracle certified engineers and oracle familiar managers on board I don't hear any complaints. It's a great product, and in all my future roles, transitioning to Oracle is one of the first things I'll do when I get on board.
The thing was, when it rolled out (2007), everyone was thrilled with it because it replaced a mainframe that you had to telnet into. That mainframe had hours of operation, i.e. you couldn't look at the course catalog at night because they shut down the mainframe to save power.
Oracle makes a ton of money because what they're competing with is just incredibly terrible.
This was last year btw.
From what your describing it seams that what was missing was an API allowing browsers to get back the uploaded files?
Was that project worth it? We didn't have much choice. Our old ERP was close to 35 years old, and no longer supported, so we were paying large sums of money just to get annual compliance updates for state & federal requirement. The new system is fine, does what it needs to do, but it's a monolithic ERP system: It does just about everything, but it's mediocre at all of it with most of it's tech perennially 4 to 7 years out of date with the best of breed. So, in the areas where we really need best of breed, we bought that and integrated it into the ERP, which is considered the "system of record". So it's fine, it works, I guess. The real kicker though is that the system we ultimately chose, while not an Oracle product, still required an Oracle DB. Fortunately we don't actually deal with Oracle as a vendor though. Our vendor is basically a VAR.
Are you sure they wouldn't like a new interface if it was actually a real improvement?
I'm reminded of a story[0] about Norwegian doctors refusing to use the new GUI system and stubbornly continuing to use the obsolete text-based system. Were they luddites? No. The old system let them quickly navigate with the keyboard in seconds while talking to the patient. The new system required them to use the mouse, so they had to spend a lot of time focussing on using the GUI, rather than helping the patient.
Encountered a similar issue many years ago at a company trying to sell a new ad booking system to Titan - they had crufty old VT100 based systems, the new one was fancy AJAX HTML whizzbangs. Exactly the same result - they could handle 5 bookings on the old system in the time it took to do one on the new (which was also terrible and ugly besides slow.)
The terminal apps, at least, have some history behind them and properly trained folks can be very fast with them.
But we're talking here about shitty early Swing-apps (or Oracle forms). If you've ever used one it can be incredibly frustrating. Moreover, people are usually just tossed into a role where they have to use these M-F-ing interfaces with no training. Who makes a table with cells too small to fit their content and where you can't resize the table? Oracle. That's who. And they're paid for it like you wouldn't believe!
To be fair, lots of software of those years were like this. SAP Ariba was just like this, and so were old Microsoft products
Sometimes, a core job of IT is eating all the pain of using the old technology that the users already know so they can go do their job and the company can achieve its objectives.
Here is the thing, the reason these people would want to keep using the software is... The replacement will be broken and they'll spend years with bugfixes and what not to get to the exact same position they're in just now.
Using old UIs isn't fun but if it works it's good enough. This is a case of everyone getting used to the workarounds until no one knew about the workarounds.
Everybody who was there when the software was created is long gone. It hasn’t been updated in decades. Nobody really knows how it works, and training is entirely folk wisdom and cargo cult practices handed down over generations.
The people that did know how to use it got constant phone calls (yeah, PHONE CALLS, because that's how these people roll) to do ad-hoc queries for management. I guess I can only fault them so far. This skill put food on their table and kept them employed even though their end product was endless dowdy bar-charts and badly formatted tables.
Now we're using a new product. It's a "BI" tool.
So many corps are doomed to repeat the bad parts of computer application history over and over and over again. In the case of "BI" or "Business Intelligence", it got it's start when middle-management got tired of begging for reports that weren't baked-in by the application vendor years ago. They started with getting permission to directly query the database (a profound coup by their standards). When they found that it was _actually_ possible to get useful information from the database, it looked like "intelligence" to them-- hence the term "business intelligence".
I have a soft spot for Citi because where else can you get 2% back on your credit card? They're not bad, they just like giving money away to their customers...
Pretty much every modern financial app I've used has one of those confirmations - some better than others but all pretty clearly state "you are going to transfer $XXXX.XX to ACCOUNT_YYYY -- click here to approve transfer".
Even venmo's quick prompt to make sure you really mean to send your pet sitter $125.00 before initiating a transfer would have avoided this problem.
The linux approach is "what you are doing is not my problem, so go do whatever you want".
For a bank, what their employees do is very much their problem.
Well, no, it's not like that at all. There IS a confirmation window; it's just not embedded in the software. Three different people -- the flunky, his boss, and his boss's boss -- were all required to confirm the validity of the transaction before making it.
> Raj then proceeded with the final steps to approve the transfers, which prompted a warning on his computer screen — referred to as a “stop sign” — stating: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” But “[t]he ‘stop sign’ did not indicate the amount that would be ‘sent out of the bank,’ or whether it constituted an amount equal to the intended interest payment, an amount equal to the outstanding principal on the loan, or a total of both.”
(from the judge's opinion, via Matt Levine and Bloomberg)
In this case it may be the best option you have, but the UX you should be aiming for is always undo.
Humans are always sure this is what they wanted to do right up until they understand the consequences. Then they experience regret. If possible design your software so that regret has a natural response in the interface in the form of an "Undo" option.
A confirmation step doesn't trigger that "understand the consequences" outcome, and so users will mostly be annoyed by the confirmation, and pick "Confirm" even when in fact they'll immediately regret that once they do it. They may even ask you to add another "Confirm" step. You want "Undo".
Notice the law here reflects this preference for Undo. If Citibank wired $500M to me the law says they get to Undo that, because they didn't owe me $500M and so that's just a mistake. They can't undo this because it looks exactly like a legitimate payment to a creditor, and if you could always undo those it opens a real Pandora's box. Normally you can "undo" paying a willing creditor because they'll just lend you the money again. But of course not everybody is a willing creditor, as in this case. Boo hoo for Citibank.
It simply should not be possible, this is about literal tons of money, they shouldn't rely on something this banal.
Simple safeguards can be put in place to prevent this. They don't even need to be very fancy:
Fairly sure a simple trained-human-readable description of what was about to happen (think: this money will go to this acct, this money here and this other money over there) would have saved this people a whole lot of grief.
"Linux gives you enough rope to shoot yourself in the foot. If you didn't think you could shoot yourself with a rope, you should read the man page first."
That said, as Linux has gotten more popular, it's put more safeguards in. For instance, you can no longer "rm -rf / file.txt".
I know someone that works for a (smaller) bank regularly processing loans in the mid six figure range. When I think about all the steps she has to go through around verification on each loan, It's just crazy to me how they're able to accidentally send an amount over 1000x times what she has to deal with.
There's a psychological defect in the human brain called Anchoring. If you are first presented with the wrong answer to a problem, it affects your ability to objectively come up with the 'right' answer. You will not catch all of the garbage I threw at you because I threw it. "Double" checking is a misnomer because it's not really doubling the number of brains.
Some things should work more like nuclear launch codes. I don't approve your action, I perform the exact same action, and if we both did exactly the same thing, then something happens. If we don't, then nothing happens or you get an error.
Might this problem still have happened? Yes. But the first time it happened would probably have been taken more seriously, instead of what we usually do: deflect, deflect, deflect.
Doctor 1 gathers evidence and makes a preliminary diagnosis and writes it down. Doctor 1 then presents only the evidence to Doctor 2. Doctor 2 comes up with an independent diagnosis and writes it down. They then see if they match.
I mean, it's better than cutting off the wrong leg, but boy is it rough.
I doubt Citi would want to pursue that sort of a suit, since it would lkely highlight they were at fault. Sure the software is probably difficult to use, but if they already knew how to use it, then using it incorrectly is not the fault of the UI.
I know you didn't mean it this literally but the issue is worse than that. They weren't confused. If they were confused, they would have sought clarification. Instead, they were sure they were doing the right thing.
Overwrite default settlement instruction
Select the ‘Overwrite default settlement instruction’ check box to confirm
that the liquidation entries should be posted into the Internal GL account.
System posts the entries to the Internal GLs only if you check this check box.
Otherwise, system posts the entries as per the settlement instructions specified
for the component of the contract.
> Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was Raj, a colleague of his in India, and a senior Citibank official in Delaware named Vincent Fratta. All three believed that setting the "principal" field to an internal wash account number would prevent payment of the principal. As he approved the transaction, Fratta wrote: "looks good, please proceed. Principal is going to wash."
However, a dev that does understand action B would be able to anticipate various forms of input from button A and how that could cause undesired results from action B.
This isn't a knock on the dev that is less knowledgable about the full thing. It is a knock on the people upstream that should be more aware of issues. Also, the people most knowledgeable about action B tend to have little to no understanding of programming. While they might understand that providing bogus data to action B can have bad results, they are not aware enough to tell the devs that sometimes valid looking data is just not sane.
I assume this system is designed to handle manually adjusted payments for syndicated lending. So you've got one borrower with potentially multiple credit facilities, with each credit facility will be funded by multiple lenders, each with potentially multiple accounts. The events you are dealing with are fees, underpayment/overpayment of interest or principal, late or early payments of principal, transfers of balances from one lender to another, funding transactions and plenty I haven't thought of or considered but are represented by check boxes on that UI.
It's complicated. The reason the system exists is because it's complicated, and prone to human error, and the before and after might generate dozens of events in dozens of accounts.
We've got four levels: info, warning, severe warning and error. Warnings are highlighted, severe warnings must be explicitly accepted (and we log this) and errors prevent submission.
When clicking on an item in the list, the cursor moves to the relevant control, so they don't have to hunt around.
We add the checks we can think of, and keep on adding checks based on user mistakes and feedback.
I'm not familiar with the financial world, so I don't know how common it would be to do what they wanted to do, but at the very least it sounds like the principal account number being filled out but not the two others is something we'd made an info item from, to highlight what would happen. If what they ended up doing is unusual, it would be a warning and likely severe warning due to the amount.
The problem is Citi itself. It's always an absurd amount of indian subcontractors who aren't paid to care but just to look good on a cost cutting plan (so they do their job), a disorganized / panicked organization who seem to never know what's happening when and follow mega-processes rather than solve problems.
My bank has those, but we can take shortcut if we must - not Citi, can make you wait 2 months for a csv file via sftp, and then pretend to be ready when you finally discover it's a frigging indian contractor writing the csv rather than an automated process... we were like "guys seriously why are you even lying about it" when it all came crashing down with crazy errors never seen in the UAT. Turns out the automation guys were late and they made an effing human do the prod version meanwhile ...
In another company, working with Citi on a completely different sector/group/vertical, I spent nights with their tech guys in India figuring out their own system and why they couldn't work... and they had less clue than me, it's absurd.
They seem to work in very split team where americans will do the high level design and then outsource to dev + support + deployment teams, ofc isolated from each other, in India. So nobody US cares about any actual implementation detail of anything, the 3 indian teams don't know each other, and nobody feels responsible of anything. It's absurd I've had multiple separate experience of the same thing, with me and my colleagues doing the connection layer between various Citi stakeholder who had no idea about each other.
There was even a time where a Citi country team in Hong Kong begged us to introduce them to the Citi country team in Singapore, and show them their product and processes...
Somewhere in there, one of the SREs said something that's stuck with me. Roughly, he said that the concept of human error is useless. Every time a human error escalates into a real problem, the deeper problem is a design flaw. At scale, human errors are a certainty, and, while documentation and training is far from useless, no amount of it can change that fact. It's therefore a critical responsibility of systems designers to design their systems to be resilient to mistakes.
For me, the best illustration is the Tenerife airport disaster, the deadliest accident in the history of aviation. Two Boeing 747 crashing into each other on the runway during takeoff.
Circumstances included fog, problems in the control tower, nonstandard phraseology, radio interference and overworked personnel.
For example, let's say a pilot belly-lands because they failed to lower their landing gear, possibly because they were distracted by some other equipment failure, or possibly because sometimes qualified and experienced pilots do this. This error could have been avoided with, say, an automated spoken "gear up" warning instead of a nonverbal warning horn (I have no idea if some aircraft already have this). But it could also have been avoided by longer and more extensive training, right?
Sure, it maybe could, but why risk it? Humans are also humans, and even pilots with endless amount of flight time does mistakes sometimes, because we're all humans. The idea is to work with the idea that sometimes we fail, even if we are well trained, so when failures happen, it's easy to recover.
> Where do you draw the line between blaming the UX and blaming the training process, or the inevitable cases where an irreversible decision made under uncertainty turned out to be the wrong one?
Basically, it's always the UX. If there is a case where the pilot made the wrong decision, something needs to change so if a pilot with similar experience, wouldn't have made that decision with a different UX. Basically force the pilots to do the right decision, always.
I'm not 100% on the history of all of this, so if someone is more familiar with it, please correct me. But I think it started with "Crew resource management" to ensure proper training of the crew. It has gone through many iterations where less and less blame is being made on the crew and more on the equipment. I think the point of the current iteration basically boils down to "Human-error will happen, let's plan for it and if human-error lead to a plane going down, let's fix it so the same error would be prevented".
That's not realistic. If you think it is realistic, please take a look at the investigation report for PK8303. Some pilots will disregard alerts, override safeties and ignore procedures: there's only so much a system can do to promote good decision-making.
https://www.caapakistan.com.pk/Upload/SIBReports/AAIB-431.pd...
If it were possible to do this, we wouldn't have pilots at all.
Generally in this sort of risk analysis there is a hierarchy of mitigation, and the least of them is training. e.g. when you find a potentially hazardous situation, the best thing you can do is design the system so that it can't happen. Failing that, you design in an procedural or workflow aspect that naturally avoids it. Failing that, you put in a system to force the use to confirm or review the action. Failing that, you train around it.
A common sign of a flawed design process is when things get pushed into the "train around it" bucket late in the process, not because they were unavoidable, but because they were looked at too late in the design to effectively make changes.
I view the procedural or workflow aspect as a subset of training. As an example, I always lower the gear and leave my hand on the gear selector until I see three green (gear safe) lights prior to selecting any flaps.
The operating handbook and factory checklists do not require this, but my planning and training has elected this optional workflow/procedure. Why? Because it's incredibly hard to get my airplane to slow down and come down for landing while completely clean (no flaps, no gear). If I use the factory accepted procedure to select approach flaps, I can get it slow enough to land. I've literally never seen a "pilot forgot the gear" airplane sitting on the runway with no flaps deployed.
Example: I have a mechanical system moving fast with enough mass to hurt the operator, so I put the control on the other side of the machine (i.e. machine body between person and the dangerous part), and require the operator to hold a switch "on" for the entire time the machine is moving.
This doesn't make it impossible for the machine to hurt the operator, of course, but it makes it a lot less likely - and it doesn't rely on training at all.
While you can also rely on training aspects like you describe (a good idea!) it's not the same thing.
I don't know aircraft, so I don't know if there is something equivalent but I wouldn't be surprised. Anything you simply have to do with two hands on disparate controls?
The only thing that I can think of that directly work this way are some of the gust locks (to prevent control surfaces from banging about in the wind while parked) are required to be designed so the airplane can’t be started and taxied out with them in place. (That’s arguably a poka-yoke as much as a procedure, but probably still fits.) Mine simultaneously locks the yoke and has a plastic flag that blocks the starter switch when installed.
If the airplane offered a mechanism to inhibit flap operation unless the gear was down and locked (a poka-yoke enforcement of my procedure), I’d decline it/argue against it. In the event of a gear failure or a forced water landing, I want to have the flaps without the gear being safe and, especially for water, I don’t want to have to look up the abnormal/emergency flap extension without gear in a QRH while doing everything else needed while descending for a forced landing.
In my aircraft, it's triggered by ((no gear safe indication) and ((full flaps) or (very low throttle setting))). The presentation is a loud, alternating warning tone and a red "Gear Unsafe" light directly in my field of view on the glareshield. These are not silenceable by button as is common on training aircraft.
Even though a handful are inadvertently geared up every year, I'm not convinced that better warning systems would significantly reduce the rate. Better training would. If I ever do the deed, I'll be the first to admit that I was the primary cause and that I failed not only to follow the checklist, but my own SOPs and flew the aircraft onto the runway with a large red light right in front of me and a blaring horn. Making it a voice seems not likely to help.
If I gear it up after an electrical failure [which some of the inadvertent ones are], that's probably slightly more understandable (and a scenario in which an additional, electrically powered, warning system would presumably also be INOP).
If the person went out of their way to perform the act, for instance they manually turned off all alarms because they wanted to take a nap, then sure, it's (largely) human error. But then you can still ask, why were they even able to turn off critical alarms? Why was there a single person involved in this apparently crucial position? What allowed us to hire someone like Homer Simpson into the nuclear power plant in the first place? And do we really want to rely on eeny-meeny-miny-moe to solve our problems? Maybe training needs to be improved, including evaluation of training results through simulations.
1. First nuclear accident: the theory is one operator was upset that another operator was screwing his wife, and removed the control rods 100% when he was scheduled to work on them, causing a sudden spike in temperature and then a water hammer that killed everyone in the building. (and made it JUMP!!!)
2. Chernobyl, although many people (specially anti-nuclear) blame the accident on the design, it was obvious deliberate error, even if the intentions weren't malicious, the operators ignored alarms, then DISABLED the alarms, and intentionally pushed the reactor past safety limits, even if it didn't had the design flaw it had, it was possible they would still find a way to blow it up if they kept their behaviour.
3. Depressed airline pilot, locked co-pilot out of the cockpit and crashed on the ground on purpose.
There are probably other situations out there... thing is, those are situations no matter how well the system is designed, it will still happen, it is impossible to make a "malicious-proof" system, after all, even a rock, with zero moving parts, can be used in the "wrong way" and kill someone.
On Chernobyl, my take away from the excellent Netflix mini-series was that there was a massive cultural failure, where everyone abdicated responsibility, and there no ability for employees to counter poor decisions from superiors. Culture and organizational design are also important components of complex systems
If you're interested in specific stories I'd recommend "Set Phases on Stun" by Steven Casey. (It shows up in the syllabus of a number of Human-Computer Interaction classes.)
But as a general heuristic: If one operator has trouble dealing with the number of false alarms you can just hire a new operator, but if most of the operators find it problematic then the problem clearly isn't with the operators.
The notable example of alarm fatigue is the designated pillow on board of the Tu-144 (the Russian copy of the Concorde) to stuff into the alarm horn. The wikipedia page is itself a “bestof” bad engineering/operating practices, which are worth a good laugh now that it is not flying anymore. See chapter “Reasons for cancellation” - https://en.wikipedia.org/wiki/Tupolev_Tu-144
Everyone does it. I’ve caught myself doing it. So I move to the previous domino and work on that.
Most telephone hardware has some form of self-checking and fault detection. Alarms are classified into "minor" and "major", sometimes also "power" or "critical". Each piece of equipment has its own alarm indicator lamps, and contacts for external alarms as well. Typically the external contacts are wired to both an "aisle light" which aggregates all the equipment in that lineup, and a floor-wide or section-wide "alarm sounder". When the sounder goes off, you look down the aisle to see which lineup has the trouble, then walk down the lineup to find the individual unit and address the problem.
But first, you push the ACO button. The alarm cutoff button silences the sounder, which won't come back on unless something new happens. ACO also tells the other workers that someone is on the case.
Crucially, it preserves attention. If the sounder was going the whole time someone was working on a repair, nothing would ever get done, because the workers would be down at the corner bar trying to get some sanity back.
The designer responsible for an alarm wants to avoid being blamed for the operator missing that specific alarm so they're incentivized to make their alarm as prominent as they can get away with. Of course once most designers are doing that then they have to keep doing it or risk get drowned out.
One way to fix that is by having someone who is responsible for the entire experience who can dictate shared prioritization, requirements, alerting frameworks, rate limiters, etc. In cases where the operator uses multiple products from different companies (e.g. in a hospital) that's especially hard which is why there's a cacophony of noise even though everyone involved acknowledges that it's a problem.
Somehow this works just fine in telecom. I was handling equipment from DSC, Alcatel, Fujitsu, Marconi, Rockwell, Cerent, Nortel, Pirelli, CarrierAccess, Tellabs, Cisco, ADC, Lucent, and more. There are Telcordia and NEBS standards for alarm severity and wiring, and everything just works when you hook it up. Does the medical industry not have standards?
Ref:
https://www.ecri.org/alarm-safety-handbook
https://www.jointcommission.org/resources/patient-safety-top...
Red lights mean that the sensors have detected a state that may damage the car or put you in danger. You should stop immediately. Examples: low oil pressure, overheat, emergency brake still on, low brake fluid. You can safely tell a new driver that if they are driving and they see a red light on the dash it means stop right now.
Yellow means that something is operating outside of nominal ranges and you should try and fix it soon. Examples: low tire pressure, low washer fluid, check engine light.
That's _one_ theory and it's not even the most likely one, it's just the only one they like to trot out whenever a History Channel producer needs to fill time between ads.
The control rods in SL-1 were prone to getting stuck in their channels for a variety of reasons. They were apparently not light either, as part of the investigation for the accident, they built a mockup control rod assembly that was weighted at 84 pounds. For military-age adult male, this is right in the range being able to move, without a lot of control over how _much_ it is moved.
It is, however, clearly a design failure that the removal of a single rod allowed the reactor to go critical, and/or that the rod was able to be removed by a human to the extent it was.
Link: https://www.youtube.com/watch?v=1xQeXOz0Ncs
One thing it discusses is how the alerts inside the control hub were so noisy, and were logged via a reasonably slow printer, that the alerts which suggested the reactor was in serious trouble only printed hours after you could do anything.
And the alert light that said "shits fucked" was placed right next to the light about an elevator being out of order.
Human error is rarely intentional, and even if it is, a system that fails in response has missed the mark. The talk explains the amazing finds made by the government committee hired to investigate the incident, once they left the idea of 'human error' at the door.
I do suggest you watch the video, but as a teaser: it turned out that at the time, most US nuclear engineers had been sourced from nuclear subs. Subs have totally different rules on how to manage the reactor, and train their staff inappropriately for a land-based reactor. Pretty significant cultural find...
[1] https://cirrusaircraft.com/story/introducing-safe-return-eme...
Of course if you are in an old airplane (private plane, or legally retired but still in use in some poor country) all bets are off.
[1] https://www.faasafety.gov/SPANS/noticeView.aspx?nid=11667
Is it possible that they could talk a civilian down in an otherwise perfectly functional jet airliner given the pilots both are totally unavailable? Yes, but it'd be really hard and I would not give them great odds for it working.
Plenty of random non-pilots won't even successfully work an airliner's radio, if you end up talking to yourself, or the passenger cabin, that doesn't help you.
In contrast what Safe Return Emergency does is really one button "Oops, the pilot is unconscious/ dead, fix it". It has the same reassuring "Don't touch the controls" you get from Waymo cars. The SRE system is flying the plane, you can best help by staying calm and maybe trying to fix the pilot if that possible. It will figure out where there's a viable landing strip it can reach, broadcast its intentions to nearby humans, fly to its chosen strip, set up, perform the landing, roll out, stop and shut down the plane.
Pushing a button is or course a lot easier. I don't want to diminishing that. However most of us can't afford the type of plane ticket where it is needed, first class on a commercial flight is an order of magnitude cheaper. Thus the odds of both pilots dead is much higher, and so knowing there is still hope may be useful.
Oddly enough, the ones who utilized it most were in the military, using the "Swiss Cheese" method of failure analysis. In order for a failure to actually occur, there had to be a complete path all the way through the "cheese", where the problem wasn't caught by any "slice". So a failure at the lowest level was also a failure at each level all the way to the top, and each level was required to figure out why it wasn't caught at their level. Very effective system.
I remember an ex-colleague saying that as an RAF person, he knew he could go on to a totally new airfield and ask for "XYZ Role" officer - and there would be an answer and direction to appropriate person.
Military knows to design also for "deceased personnel" (redundancies etc)...
So many IT outfits have problems that come back to "Oh, that was going to Bob and Bob left" and it infuriates me every time I see it, because we've known for decades how to avoid this problem.
There is a huge problem in the civil service of information being local to teams. Important information sots in inboxes or a shared drive if you’re lucky.
Finding out who to contact in another department on a given topic can take days and usually requires asking your private office to check (because they at least have the other department’s private office contact details). Otherwise people just look for emails in published documents and email out in the hope that at least one of them still works in the right department.
This could all be so easily solved with permanent, shared mailboxes per team. I suspect the reluctance is in part due to how much easier it would make FOIs.
Military needs consistency, predictability, and uniformity. It needs a lot of good management practices to achieve that with people and parts that are not consistent, predictable, or uniform.
Companies tend to focus on chiseling pennies and hope for the best.
https://www.npr.org/2018/08/27/642310810/you-2-0-check-yours...
Page 2 of this link goes into a useful breakdown
https://sma.nasa.gov/docs/default-source/sma-disciplines-and...
It would make the error much easier to spot.
OTOH, the people approving may not have the right to see values, just the process part they are involved in.
This and the aerospace mention reminded me of John Glenn: "two million parts, all built by the lowest bidder".
"Doors can have two states: open or closed. They should not require instruction."
Also there is that fun state of “open but will lock behind you because the doorknob lock does not prevent you from closing the door, hope you have your keys on you or someone inside” though that’s maybe more a special case in the state transition table than an actual state?
How could we tolerate such an awful design? Who is responsible for this catastrophe?
I don’t think a door people regularly walk into out of confusion is a good one.
Sadly.
* ie: Defend (with passion!) the flawed tools, and resist attempts to fix or change them by something better
If only the people who insist on using unsafe languages understood this. Their position is that you should get better at not making mistakes.
Anyone who thinks they can overcome 100% of memory-unsafety bugs through looking at the code real hard is fooling themselves. But I'm not convinced there's a lot of people who actually think that (maybe there's some people who just don't care or never considered it)
Obviously they may not know these conditions ahead of time. But preventing user error for known problems seems obvious.
Had the social structure been politically different on that day they would have acted on the available engineering information by refusing to launch. It was the political environment that goaded them into taking more risk than they had previously decided was acceptable.
It's written by someone that does airliner crash investigations. His central point is that "human error" as a term functions to redirect blame away from the people who establish systems and procedures. It blames the last domino vs the people who stacked them.
It's a quick breezy read, and you'll get the main points within the first 30 min or so of reading. I've found it useful for getting these ideas across to people though, especially more generic business types where "no blame post mortem" strikes them as some care bear nonsense rather than being an absolutely essential tool to reduce future incidents.
And then proceeds to use reductio ad absurdum to demonstrate that if you can be perfect for 5 seconds, you can string those together to be perfect for 5 minutes ... 5 hours ... 5 days .. your whole life!
And when someone in the crowd pushed back on this idea, the consultant said something like, "If the airlines took that same approach to flying, we'd have 1,000 accidents a year!"
And then maybe the reader looked it up later and it turned out there were about 1,000 flying accidents a year.
They all thought they were making the right transaction. There was no warning that they were not.
It would be like if I hit the reply button here on Hacker News and instead of the comment I typed out it my reply contained my bank account information. And I was not told something I do not want to happen would happen by doing so.
Thanks for the explanation. It saddens me how brutal people here are in response to a misunderstanding, judging by the downvotes, but oh well.
The solution they came up with was a "Grinder Off" button that lit up to indicate the grinder was turned off. It was...confusing to say the least. And as an infrequent user of this coffee maker it was all too easy to screw up. To add insult to injury, that off light turned off (i.e. enabled grinding) every time you brewed a new pot. You had to be sure to press it every time you brewed from pre-ground beans, which was always for us.
That coffee maker is well designed for its intended happy path use case, which is not the same as you can say for this Oracle software.
I think what threw me is the "grinder off" button with a red light. The red light made sense in the context. But, if I were designing this, I would have a "grinder" button with a green light that was default "on", indicating that grinding was imminent. There was no green light on this part. It was red or off.
That would have been consistent with the rest of the interface, where a green light on the "brew" dial meant the timer was set and a red light meant the coffee had brewed.
I have a hot water stand-by boiler in my kitchen a $15 outlet switch because the darn thing didn't come with a simple power button. Hardly anything these days does. All of which is to say, the ideal design often conflicts with the consumer's other expressed preference of "lowest price possible, it doesn't matter how many corners are cut and how quickly it dies".
So many things should be "preserved state" switches, but people put up with it. Not sure why.
My digital kitchen scale turns off pretty quickly after use. This is terrible, because it also doesn't remember tare (i.e. the weight of the empty container you put onto the scale prior to filling it), so when you turn it back on it zeroes on whatever's on the scale. Did not read the measurement immediately, or forgot the value? You now have to empty the content into another container and try again. Annoying if you're measuring uncooked rice. Infuriating if it's sticky, ultra-viscous fat.
My dishwasher has a "COMPLETE" light that tells the household that a washing cycle finished after the door had last been closed, a signal that the contents of the dishwasher are likely clean (unless you leave the light on after emptying, but we rarely forget). But if you close the door accidentally just once after that, the light stays off, and there is absolutely no way to put it back on without a washing cycle. I read the manual, tried various logical and illogical key combinations, nothing. Now you have to tell your household "I didn't have time yet to put all the clean stuff out but the light is off, please remember that".
My TV likes to switch automatically to its internal speakers for various reasons, which I never want to use because they are terrible in this particular TV, and switching back requires going through multiple laggy submenus. But worse, if I turn the TV on and notice it's on internal speakers again, I have to wait for it to finish booting completely before I'm allowed to navigate the laggy submenus.
To leave this rant on a more positive note, though: The digital interfaces of my coffee maker, my microwave, and my water cooker (multiple temperatures, auto-reheat, auto-shutoff) seem to do exactly what they should, under many and sometimes non-trivial circumstances, so I'm glad good UX design still exists.
Search for "dishwasher magnet", which is made exactly for this.
WTF else would you want the behaviour to be?
It's a feature.
Unload this dishes and load the dispenser. Simple and automatic.
Horizontal is dishes are clean
Vertical is dishes are dirty
Simple problems demand simple solutions
On top of that you're also supposed to clean and dry the grinder parts after every use or it eventually gets clogged. I just switched to pre-ground coffee and a simpler coffee maker.
You are about to send $83,932,198.83 to (various account information fields)
Unlike, say, a site that sells hand knit mittens or maybe organic kibble.
https://news.ycombinator.com/item?id=26170694
:-)
The next paragraph continues:
Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was Raj, a colleague of his in India, and a senior Citibank official in Delaware named Vincent Fratta. All three believed that setting the "principal" field to an internal wash account number would prevent payment of the principal. As he approved the transaction, Fratta wrote: "looks good, please proceed. Principal is going to wash."
The business banking portal is often much worse than the consumer one.
Nowhere in the article (which I read in its entirety) does it answer the above reply's question. "Do companies consider good UI a competitive advantage when looking for a commercial bank or lender?" I don't know. But that's not addressed in the article.
My guess is that it probably isn't a huge consideration. Very few people interact with these interfaces. Maybe one or two controllers at a company would ever log into this. Even CEOs and top management would never actually log into these accounts directly. They are going to get their information from internal reports and BI dashboards. So I bet no one really cares. If Citi offers a $400M loan at 1.1% interest and JP Morgan offers the same loan at 1.3% interest, my guess is that that company is going with Citi. I doubt UI/UX makes a difference here. Although in the consumer world it does have an impact which is why we have seen many banks improving their apps and websites lately to compete in the consumer banking space.
Ive gone so far as to open 4 accounts with different banks to do actual tests
The biggest issue i found is that no bank offers a "free trial" of its own to facilitate discovery.
I have filled at least a dozen firms twice becuase the bank wants "wet ink" signatures
I had to overlook those instances just so i could test the UI, but honestly, its an exercise in supreme patience and i am afraid my whole effort will be pointless. I suspect all 5 banks will be equally bad.
In the case of b2b, it’s more complicated. You’re selling to office administrators, whose goal is to score the best deal for the company. Since they aren’t the primary users of the product, stuff like UX doesn’t matter as much as cost.
Best illustrated by Slack, which thought they could sell to businesses based on a beautiful UI, but their market was dominated by Microsoft Teams, which could sell better to enterprises.
Which is probably one reason why Slack is looking to sell to Salesforce.
My point being I don't think Slack's positioning was "chat but prettier". The fact Teams is more dominant now seems more to do with bundling.
Teams dominates because Microsoft gave it away for free to those who were already paying Microsoft.
But, you know what? Nobody cares about my opinion! You are exactly right: the people who make these decisions about what software the university "runs on" are at a far higher level, and have far more clout. Their incentives are totally misaligned with mine -- I use linux as a daily driver, and write highly mathematical software. I am exactly _not_ the target audience of these things, because, frankly, I can support myself: if something's broken, I fix it -- and don't consume IT's time. The people who _do_ however, are all of the admin staff, many of whom have professional backgrounds elsewhere, and think this is the way the world works. And they get promoted, and end up in managerial roles that make purchasing decisions at a high level. Hence, Teams.
But hey, nobody was ever fired for using Microsoft.
Sure but until the UI is so bad that you end up accidentally sending out money you didn't intend to, it is important.
Separately, In the business UI I used previously with Citizens it was so easy to get locked out of your account (and I had no time for phone calls, which was the only way to unlock it after that) that so many payments were made late because I had no other choice; my schedule was already full and the payment would only be made when I could schedule time for that stupid phone call.
That led to delays and late fees of sorts, and that is money as well, all because of a bad UX.
One day, a novice-level Java error in Oracle’s code caused a multi-day outage requiring data to be restored from backups and reloaded to get any functionality back and several months of that group deploying duct tape to get everything working.
For a consumer app, people would leave in droves as one star reviews poured in. In this case, they solved this by inviting the relevant VP to a football game in the corporate box with the account rep, both of the same fraternity, and starting that Monday nobody in management talked about the outage publicly again.
This UI is pretty good ! Haha. No seriously today we had a one hour conversation on what happen when a user cancel a trade twice. I don’t think we’re gonna find a elegant solution within the contraints of the clusterfuck of sub-system we maintaining. Kinda disheartening.
If I am an approver of a $900M transfer using an edge case I will follow instructions:
"Citibank’s internal Fund Sighting Manual provides instructions for suppressing Flexcube’s default. When entering a payment, the employee is presented with a menu with several “boxes” that can be “checked” along with an associated field in which an account number can be input. The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL” — meaning that the employee had to check all three of those boxes and input the wash account number into the relevant fields." [1]
[1] https://www.bloomberg.com/opinion/articles/2021-02-17/citi-c...
Conway's Law applies here. It's a hugely dysfunctional bank, saddled with bureaucracy, fragile software (company change control ran on a IBM mainframe as late as 2015, requiring IE6), teams that are 'silo-ed', and talking with other teams are often the equivalent of a divorce lawyer's communication between spouses.
Sandy Weill's crowning glory of mashing together Salomon Brothers, Smith Barney, Primerica, Travellers, Citicorp, and Diner's Club.
Interesting. My gut reaction was that they must have initially published his name and silently redacted it. Your gut reaction is that HN is seething with many racist commenters who use R__ as an epithet for any Indian contractor.
Wayback Machine if you haven't already figured out which one of us is right.
Citi learned the hard way, which is good, as it's the only way for such an org to learn.
Do we have evidence that they actually learned anything from this?
I can't imagine it's any different in Citibank.
Having worked for companies the size of small startups up through megacorps, my experience has been that megacorps can be unfathomably foolish in these kinds of things.
I'd expect Citibank to be less likely to learn (and apply) the right lessons from this experience, than a small or medium-sized business would.
If Revlon defaults on the loan entirely, then the money evaporates.
The biggest problem is this whole notion of "fake-paying" off the principal as the means to calculate accrued interest by essentially piping the actual repayment to /dev/null but actually forcing the user to type /dev/null 3 times
Of course it would - simply have a different top of the decision tree that would hard code "PRINCIPAL REPAYMENT" in one and "NO PRINCIPAL REPAYMENT" in another. Do not allow filling out details on the screen that selects the flow.
The number typed was correct, and it was even in the correct location. It was that it was not also included in two other locations that caused the payment to go through in the incorrect manner.
Given the assumptions presented by the UI, I’m not sure anything other than an extremely detailed confirmation dialog showing exactly where the amounts were going would have solved the problem.
Even then it’s not clear to me that that info would even be available given that the software never seemed to have been designed for the use case of a partial payment in the first place.
Edit: Removed accusation.
> The mistake wouldn't have mattered much...
Accidentally sending nearly 1 Billion dollars is a pretty big mistake and it matters a lot. You can't just be throwing hundreds of millions of dollars into people's accounts and think its not a big deal because they will "probably" give it back.
It seems noteworthy because they didn't quickly restructure the debt. They weren't throwing money into random accounts, they accidentally sent payments early.
(I am not sure what this policy means if one of the three people has lost an eye; presumably it requires a fourth approval.)
resulting in issues like Citi got. Seriously who thought that UI, requirements, text, and all, was a long term solution for handling any amount of money?