3 ms·
> at least aim for I am a former bank dev. The "aim for" is where the argument really falls off the wagon. It would be one thing if banks actually achieved an
by throwawaysleep 4y ago
> at least aim for
I am a former bank dev. The "aim for" is where the argument really falls off the wagon. It would be one thing if banks actually achieved anywhere near that. They don't.
Banking tends to aspire to that in its memos and docs, but falls utterly short and when it falls short, it doesn't look introspectively, but rather just edits the documents and data or changes definitions or slowly lets the initiative die by having people shuffle roles.
PCI? One of the things that was supposedly for PCI was proof of controls on code, i.e. that someone had reviewed the code and someone approved the release and who those people were. PCI Requirement 6.3.2.
Sometimes we theoretically had the controls, i.e. approval by another dev was required to merge code. But plenty of times, they turned them off due to the ticket burden. Even when controls existed, the approval would come seconds after the PR was created. There was no review.
In the docs, only our lead could send something to prod. In practice, anyone could. There was no management oversight or approval really required and nobody was monitoring it.
Also, we once sent the dev site to prod. There was no significant segregation between development and prod environments. It was considered too much work. This is also a violation of PCI requirements.
Banks theoretically work to strict standards. At least at the one I was with (someone tried to buy it for 30 billion or so), massaging whatever we had to meet the standards was how things worked. We didn't rise to the standard. We didn't change how we did things. We edited, weasel worded, and frankly, probably lied our way to meeting them.
A friend is currently with a bank you have heard of. He is not quite a developer, but on a team that does dev work. They have standards for reliability and productivity. He fakes them. He gets to toss any bad data as a "outlier" and sends the rest up to management for its rubber stamp. He is upfront about it in the way that bankers are (a pile of weasel words), but realizes that VPs are Banks are not technical. Called the supposed procedures they follow a "load of horseshit they are never going to check."
- ggm 4y agoBut thats all implicitly a risk in almost any large deep-time sw house. They said it all with "bad fit" -Banking isn't "why" they're a bad fit, its a niche.
- icedchai 4y agoI once worked in a "regulated" industry where the product was "certified" by a third party before going live with the customer. It handled money, but was outside of banking (picture something like sports betting.) The third party had access to the code, but didn't look at it or try to build it. They purely ran manual QA, black box-type tests, then gave it their stamp of approval. This was in the old days, years before git or GitHub. There were no code reviews. There was maybe 5 unit tests in the whole code base, and they were run manually. As developers, we had full production / root access with essentially zero oversight. I had a VPN into this stuff from my house. If I screwed something up bad enough, we probably would've received a visit from a Tony Soprano-like character, so that was probably enough of an incentive to keep things working.
- badpun 4y agoFWIW I've worked in global top50 bank on a non-critical team (nothing we did affected real bank balances or transactions) and nothing of the sort you're describing was happening there. The rules were followed, even if they were extremely painful for developers. In fact, they were main of the reasons people left the bank - they just wanted to go someplace where their hands aren't tied as much. So, I guess there are good banks and bad banks.