Absolutely true.
-
RE: https://mstdn.ca/@charette/116127384919473905
Absolutely true.
(For those who haven't dealt with banking IT: banks are in the business of managing financial risk, and it doesn't get any riskier than allowing an enthusiastic intern who occasionally lies to you and hallucinates on the job to refactor a 60 year old code base that nobody really understands, without oversight, that handles all your customers' money. The phrase "sued into a smoking crater of banking wreckage the instant anything goes wrong" springs to mind!)
@cstross even the most, seemingly, off-the-wall ideas, are careful risks, which are properly underwritten. There are many others, and starting a Free* ISP from scratch in 1998, with the payoff that with enough people on the internet that they would be able close bank offices, as everyone will be enabled to do electronic banking easily. This was ofcourse proceeded by this bank introducing electronic banking about 5 or 6 years earlier
*Free, as in there were other ways to ensure the losses weren't too high
-
@quinn @jzillw I spent a few years doing back end dev in a payment service provider that hooked into all the big British high street banks. About 10% of their managers were brilliant, 70% were a waste of oxygen, and 20% were clearly undercover anarchists seeking the downfall of capitalism by weaponizing Svejk-like cheerful ineptitude.
-
@quinn @jzillw I spent a few years doing back end dev in a payment service provider that hooked into all the big British high street banks. About 10% of their managers were brilliant, 70% were a waste of oxygen, and 20% were clearly undercover anarchists seeking the downfall of capitalism by weaponizing Svejk-like cheerful ineptitude.
-
RE: https://mstdn.ca/@charette/116127384919473905
Absolutely true.
(For those who haven't dealt with banking IT: banks are in the business of managing financial risk, and it doesn't get any riskier than allowing an enthusiastic intern who occasionally lies to you and hallucinates on the job to refactor a 60 year old code base that nobody really understands, without oversight, that handles all your customers' money. The phrase "sued into a smoking crater of banking wreckage the instant anything goes wrong" springs to mind!)
@cstross Is that what happened in 2008/9?
-
@mkoek @cstross @quinn My almost entire experience is in video game development, i.e. a completely different space, and the 1-7-2 ratio holds, except instead of anarchists we get tech bros who are clearly trying to milk the project's funding dry and don't care if it collapses as a result.
(roughly 15% of commercial game development projects are ever completed; of those that see release, roughly 15% are financially successful)
-
@cstross On the other hand, my brother chose a career as a programmer for banks around the year 2003. Every single job he had back then just added to his personal list of banks where he wasn't going to keep his money. He had seen their backends and was afraid. I distinctly remember one particular job where his boss was the CEO's wife who knew nothing about software engineering and wasn't above e.g. testing in production.
i.e. sometimes banks manage financial risk by allowing it.
I have a friend who has run loan operations in small to mid-sized regional banks her whole career and it's kind of amazing that none has gone down hard
yet, just on the basis of systems issues. The companies merge repeatedly and each successor enterprise is a frakenstein's monster of old systems from each previous merger held together by baling wire and bubble gum. Throw vibe coding into the mix and the whole jenga pile (to mix metaphors) may finally come tumbling down. -
@cstross Is that what happened in 2008/9?
@8r3n7 My experience was of '96-2000.
In 2008/09, half the main banks in the UK were nationalized to stop them going bust and taking half the populations' mortgages and savings with them. They ended up back in private hands again a decade later.
-
I have a friend who has run loan operations in small to mid-sized regional banks her whole career and it's kind of amazing that none has gone down hard
yet, just on the basis of systems issues. The companies merge repeatedly and each successor enterprise is a frakenstein's monster of old systems from each previous merger held together by baling wire and bubble gum. Throw vibe coding into the mix and the whole jenga pile (to mix metaphors) may finally come tumbling down.@jawarajabbi @jzillw @cstross This is exactly how the banking system is, even large banks, & the work of integrating or migrating those systems is frequently farmed out to consulting firms (ask me how I know). It’s all fragile, held together with tape, & breaks all the time.
I’ve been away from that world for a bit, but I think it’s very likely those people would be looking at LLMs as a godsend.
-
@quinn @jzillw I spent a few years doing back end dev in a payment service provider that hooked into all the big British high street banks. About 10% of their managers were brilliant, 70% were a waste of oxygen, and 20% were clearly undercover anarchists seeking the downfall of capitalism by weaponizing Svejk-like cheerful ineptitude.
@cstross
'Cheerful ineptitude' is a glorious term which I will use without restraint from now on. -
RE: https://mstdn.ca/@charette/116127384919473905
Absolutely true.
(For those who haven't dealt with banking IT: banks are in the business of managing financial risk, and it doesn't get any riskier than allowing an enthusiastic intern who occasionally lies to you and hallucinates on the job to refactor a 60 year old code base that nobody really understands, without oversight, that handles all your customers' money. The phrase "sued into a smoking crater of banking wreckage the instant anything goes wrong" springs to mind!)
@cstross Also, we don't need to vibecode this, just do it carefully.
I was once involved with a company that did semi-automated COBOL->Java translations, with very good effect. The way I understand it, the end result you got was the business logic in reasonably decent, maintainable(!), Java, which then called into a monstrously gigantic "Do what COBOL would have done here" library for the actual calculations.
It wasn't cheap, but it was also not half-assed.
-
@bituur_esztreym @cstross @quinn It also shortens to a nice acronym that sounds way less insulting than it really is ("WoO manager", "he has WoOed all the way through this project", "that's a glorious pile of WoO").
-
RE: https://mstdn.ca/@charette/116127384919473905
Absolutely true.
(For those who haven't dealt with banking IT: banks are in the business of managing financial risk, and it doesn't get any riskier than allowing an enthusiastic intern who occasionally lies to you and hallucinates on the job to refactor a 60 year old code base that nobody really understands, without oversight, that handles all your customers' money. The phrase "sued into a smoking crater of banking wreckage the instant anything goes wrong" springs to mind!)
@cstross As a person, who was working in banking IT: yes, but no.
I do not know, how that matches other banks, but for me that was: they were risk averse, because of that they were conservative, and that has caused another class of problems.
There was one delivery a colleague working in another dept was working on. The delivery required some changes in the storage configuration. It was well tested and documented, and it was sound. However, to make a change on production they needed a blessing from involved department. And, obviously, they needed one from the storage guys, as they will be implementing this part of the change. And they said: sorry, not this quarter.
There was a rule for dept managers: three strikes and you are out. Three serious fuckups (affecting prod) happen during a quarter in your dept, and you're fired. Doesn't matter, if you're at fault.
So, the storage dept has a serious h/w failure already. You know, those pesky spinning rusts decided to get more rusty. And the manager wasn't keen to take any new risks this quarter.
-
R relay@relay.an.exchange shared this topic
