Comment by Frummy
3 years ago
In front of your eyes: TSO-ISPF for everything. IDz for the 5 seconds per month that code is actually written
Test env: Separate permanent envs. From playground where nothing matters, env with some fake data in similar databases and variants of all systems, to mirror of prod with anonymised data, then prod
There are dummy online banking web interfaces
What sets it apart is that the operating system is painful to use and never stops being painful to use. And your employer is paranoid and keeps you in a digital prison for security so very few permissions so there is no creativity or off-road improvisational innovation just assemblyline style development
> And your employer is paranoid and keeps you in a digital prison for security
That, um, sounds reasonable to me in the context of what they're developing.
>> the operating system is painful to use and never stops being painful to use.
But this is regretful, and slows down everything by orders of magnitude. One of the big problems is lack of EFFICIENT documentation/Quick Starts. The guides are labrynthine in layout, looping and colliding spiders' webs of wtfness.
Not really.
Access to production and its data should be highly regulated. Ideally no dev machine has any kind of write access to prod - instead it's commit access to a (non-master) branch which needs multiple approvals to be merged into a release branch.
Access to dev environments and their local code? Who cares, let them explore. As long as all code is reviewed prior to deploying, they could even be developing on a compromised machine and the live system will still be secure.
Practically, if your dev machine was compromised by a targeted attacker, they could create commits using your identity and if they compromised another dev machine could approve those commits using their identity. Then the attack would only be visible in commit logs with low odds of discovery before release to prod.
I'd rather not have "off-road improvisational innovation" with the nation's banking infrastructure, thanks. If that's what you want to do go write another JS framework or static site generator, don't work at a bank.
Your gut reaction is disgust and I don't blame you. You could do without the insults, however. The "nation's banking infrastructure" is outdated and messy. There is no chance in the entire world to upgrade it or clean it up if we the workers are not equipped with the power to do so. A first step could be informational transparency, I would for example really like read access on other systems in the bank and not just my own. Truthfully, separation of duties in this case is more of a controlling function and less of a security function. Of course I care about security, we all do. But let's not stifle the workers that can change the system from within in such low risk work that it's bordering on fear of change. Don't insult me again on something you know nothing about and haven't seen with your own eyes.
It was the royal you, so was not an insult.
I think anything that could be appropriately described as infrastructure could also be described as outdated and messy, so that's not necessarily a reason in and of itself to let people experiment on banking infrastructure. Are software engineers (again, the type who end up working for the federal government and banks and government contractors) any more qualified to experiment on this stuff than people who have working in banking and finance?
1 reply →