4 ms·

Thing is, even with a UI as shitty as this, you would still have caught this if before actually committing the transaction, the software had a "before" and "aft

by m12k 6y ago

Thing is, even with a UI as shitty as this, you would still have caught this if before actually committing the transaction, the software had a "before" and "after" view to show the effect of the change. Raj caught the error during a routine inspection the next morning, so the same view he used for that, presented before the change had been committed, would have allowed him to avoid the error.

pdpi 6y ago
That would, by itself, make the UI less shitty. Also, if you're the sort of person who thinks in those terms, you're also likely the sort of person who'd have come up with a better design overall anyway.
- dylan604 6y ago
  This sounds like one of those situations where devs tasked with programming something that they have little to no understanding of what they are programming does. Yes, the dev programmed button A to perform action B, but doesn't truly understand how/why/what/when/where action B. It's just a check box of the requirements that has now been completed. 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.
  - acdha 6y ago
    I wouldn’t even assume lack of understanding as much as being locked into a work-to-order situation where they’re not rewarded, possibly punished, for doing anything which isn’t on the assignment. This is super common in outsourced hellscapes where the MBAs like to LARP as architects and UI designers and there’s no effective feedback loop from the actual users.
JackFr 6y ago
In this case, yes, in general I doubt it. 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.
skeeter2020 6y ago
What seems weird is that accounting software typically adds these transactions immediately with a future date, so in this case whenever the batch was executed. You don't need to wait to see the impact, just for it to take effect. This UI has to work extra hard to obscure this visibility.
- PeterisP 6y ago
  I don't know how it's in this particular system, but I have also seen banking core software which would add these transactions during end of day batch procesing, by which time the original operators wouldn't be looking at them anymore, and anything that should be settled 'today' would also get executed during that batch process.
magicalhippo 6y ago
At work we have several modules which each have their "output control". When the user hits "submit", we run several checks and outputs a list of potential issues. 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.
SamBam 6y ago
Right. I think this situation needs a "Dry Run" button.
- microtherion 6y ago
  I had exactly the same thought. Whenever I write a tool that manages a complex process, I try to add a dry run mode, and more often than not, I use it.
xwolfi 6y ago
I've worked with Citi as a partner, as a client and as a service provider in various other banks and fintech companies, and I'm so not surprised. In fact none of my colleagues are. 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...
- ThankYouBernard 6y ago
  oh there it is, the usual expected racist comment.
- rowland66 6y ago
  Your experience with Citi is very similar to mine. It is funny that as an organization Citi seems to believe that its technology is brilliant and that any software that it uses must be built by Citi. Tremendous hubris combined with total incompetence. Not a winning combination.

by m12k 6y ago

pdpi 6y ago

That would, by itself, make the UI less shitty. Also, if you're the sort of person who thinks in those terms, you're also likely the sort of person who'd have come up with a better design overall anyway.

dylan604 6y ago
This sounds like one of those situations where devs tasked with programming something that they have little to no understanding of what they are programming does. Yes, the dev programmed button A to perform action B, but doesn't truly understand how/why/what/when/where action B. It's just a check box of the requirements that has now been completed. 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.
- acdha 6y ago
  I wouldn’t even assume lack of understanding as much as being locked into a work-to-order situation where they’re not rewarded, possibly punished, for doing anything which isn’t on the assignment. This is super common in outsourced hellscapes where the MBAs like to LARP as architects and UI designers and there’s no effective feedback loop from the actual users.

JackFr 6y ago

In this case, yes, in general I doubt it. 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.

skeeter2020 6y ago

What seems weird is that accounting software typically adds these transactions immediately with a future date, so in this case whenever the batch was executed. You don't need to wait to see the impact, just for it to take effect. This UI has to work extra hard to obscure this visibility.

PeterisP 6y ago
I don't know how it's in this particular system, but I have also seen banking core software which would add these transactions during end of day batch procesing, by which time the original operators wouldn't be looking at them anymore, and anything that should be settled 'today' would also get executed during that batch process.

magicalhippo 6y ago

At work we have several modules which each have their "output control". When the user hits "submit", we run several checks and outputs a list of potential issues. 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.

SamBam 6y ago

Right. I think this situation needs a "Dry Run" button.

microtherion 6y ago
I had exactly the same thought. Whenever I write a tool that manages a complex process, I try to add a dry run mode, and more often than not, I use it.

xwolfi 6y ago

I've worked with Citi as a partner, as a client and as a service provider in various other banks and fintech companies, and I'm so not surprised. In fact none of my colleagues are. 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...

ThankYouBernard 6y ago
oh there it is, the usual expected racist comment.
rowland66 6y ago
Your experience with Citi is very similar to mine. It is funny that as an organization Citi seems to believe that its technology is brilliant and that any software that it uses must be built by Citi. Tremendous hubris combined with total incompetence. Not a winning combination.