|
Post by Ton ⓉⓞⓃ on Mar 1, 2021 20:38:42 GMT
Poor internal webpage design is blamed for an overpayment of $500m that can't be recouped by Citi judge says.
I just hope internal web pages aren't as bad as some of the external ones I see
|
|
|
Post by mfaxford on Mar 2, 2021 9:50:04 GMT
Not sure that's a web page, it looks more like a desktop app. But that's still horrible UI design!
Some of the comments describe it as being like a 90's application and I'd agree from the screenshot.
What's more three separate people had eyes on that transaction and thought it was doing the right thing.
Whilst an expensive lesson it looks like a vital one for them to have had.
|
|
|
Post by Deleted on Mar 2, 2021 10:11:04 GMT
Another terrible website...
|
|
Nomad
Member of DD Central
Posts: 727
Likes: 494
|
Post by Nomad on Mar 2, 2021 10:27:17 GMT
Another terrible website...
And another three - EE NowTV FreeSportsPlayer Citibank has always been fine for me (but no overpayments ), US & UK.
|
|
|
Post by Deleted on Mar 2, 2021 10:51:25 GMT
Yeah, that looks like internal software, not a webpage.
As someone who bears the scars of many years of systems integration work for banks like this, I can tell you with certainty - most big retail bank systems (Citi, HSBC, etc) are NIGHTMARES of bodged-together tech from DOZENS of previous mergers.
The systems are like a combined historical record of the banks entire M&A history and a 'history of computing' textbook all rolled into one.
So you often have modern cloud/mobile front-ends built on top of 1990s era Unix clusters from a previous merger which communicate with 1970s mainframe tech from the merger before that... etc etc
I'm surprised I escaped with my sanity intact. Or maybe I didn't...
|
|
adrianc
Member of DD Central
Posts: 8,874
Likes: 4,753
|
Post by adrianc on Mar 2, 2021 11:18:55 GMT
Yeah, that looks like internal software, not a webpage. As someone who bears the scars of many years of systems integration work for banks like this, I can tell you with certainty - most big retail bank systems (Citi, HSBC, etc) are NIGHTMARES of bodged-together tech from DOZENS of previous mergers. The systems are like a combined historical record of the banks entire M&A history and a 'history of computing' textbook all rolled into one. So you often have modern cloud/mobile front-ends built on top of 1990s era Unix clusters from a previous merger which communicate with 1970s mainframe tech from the merger before that... etc etc I'm surprised I escaped with my sanity intact. Or maybe I didn't... Which is exactly why COBOL developers (many closing on retirement) were in such high demand in the run-up the Minnelium. Because they were the poor sods that had knocked the software up in the first place without thinking it'd still be in use at the point four-digit years would be required. And, in true Goldilocks style, they're still there...
|
|
Greenwood2
Member of DD Central
Posts: 4,217
Likes: 2,669
Member is Online
|
Post by Greenwood2 on Mar 2, 2021 20:43:10 GMT
Yeah, that looks like internal software, not a webpage. As someone who bears the scars of many years of systems integration work for banks like this, I can tell you with certainty - most big retail bank systems (Citi, HSBC, etc) are NIGHTMARES of bodged-together tech from DOZENS of previous mergers. The systems are like a combined historical record of the banks entire M&A history and a 'history of computing' textbook all rolled into one. So you often have modern cloud/mobile front-ends built on top of 1990s era Unix clusters from a previous merger which communicate with 1970s mainframe tech from the merger before that... etc etc I'm surprised I escaped with my sanity intact. Or maybe I didn't... Which is exactly why COBOL developers (many closing on retirement) were in such high demand in the run-up the Minnelium. Because they were the poor sods that had knocked the software up in the first place without thinking it'd still be in use at the point four-digit years would be required. And, in true Goldilocks style, they're still there... We used after or before 50, as a 2 digit year check to give, if less than 50 2000+ if more than 50 1900+ to avoid huge re-writes, quite an easy update to our code. Will work until 2050.
|
|
|
Post by mfaxford on Mar 2, 2021 22:23:03 GMT
We used after or before 50, as a 2 digit year check to give, if less than 50 2000+ if more than 50 1900+ to avoid huge re-writes, quite an easy update to our code. Will work until 2050. And what's the betting a few of those bits of code are still in use in 2050, that's assuming they make it past 2038 first.
|
|
Greenwood2
Member of DD Central
Posts: 4,217
Likes: 2,669
Member is Online
|
Post by Greenwood2 on Mar 3, 2021 8:13:31 GMT
We used after or before 50, as a 2 digit year check to give, if less than 50 2000+ if more than 50 1900+ to avoid huge re-writes, quite an easy update to our code. Will work until 2050. And what's the betting a few of those bits of code are still in use in 2050, that's assuming they make it past 2038 first. Hopefully all the projects that ran over from the 1990s to the 2000s will be long finished by now, I was just happy we got continuity of data over the change in century, not my problem any more.
|
|
adrianc
Member of DD Central
Posts: 8,874
Likes: 4,753
|
Post by adrianc on Mar 3, 2021 8:22:00 GMT
Which is exactly why COBOL developers (many closing on retirement) were in such high demand in the run-up the Minnelium. Because they were the poor sods that had knocked the software up in the first place without thinking it'd still be in use at the point four-digit years would be required. And, in true Goldilocks style, they're still there... We used after or before 50, as a 2 digit year check to give, if less than 50 2000+ if more than 50 1900+ to avoid huge re-writes, quite an easy update to our code. Will work until 2050. I hope that doesn't get used for things like repayment dates for 30yr mortgages... Or dates of birth. Or...
|
|
Greenwood2
Member of DD Central
Posts: 4,217
Likes: 2,669
Member is Online
|
Post by Greenwood2 on Mar 3, 2021 8:45:58 GMT
We used after or before 50, as a 2 digit year check to give, if less than 50 2000+ if more than 50 1900+ to avoid huge re-writes, quite an easy update to our code. Will work until 2050. I hope that doesn't get used for things like repayment dates for 30yr mortgages... Or dates of birth. Or... I wouldn't have advised it in all applications, but it was a good short term fix for ongoing projects where you had to have continuity of data and didn't want to be messing too much with the code on a live project.
|
|