> It needs punishment for the management who doesnt allow time to set things up properly
Hard to show it was management's fault, and not the result of a developer who really didn't have the AWS skills (though that's probably still the fault of management, for not verifying skillsets before hiring or giving AWS keys)
Everything we know about iteration cycles, quick access to devops resources, etc, will change when prison time becomes an option.
> Hard to show it was management's fault, and not the result of a developer...
No. A leader is ultimately responsible for everything that happens or fails to happen under his or her leadership. Full stop.
The people in charge of your hypothetical developer are the only ones with the ability to put processes in place to prevent it from happening. They are the least-cost avoider. Therefore, the power and the responsibility belong there.
Strict liability for the least-cost avoider is a sound strategy from both a moral perspective and a law & economics perspective. When proving knowledge and proximate cause are difficult, and someone is clearly in charge, and the harm is great - you place the liability on the people in charge whenever something goes wrong, and be done with it.
As a member of upper management, how would you address this then? More QA? More management of development practices? Move way from "devops" and back toward a world where there's a clear isolation between ops and development?
Over the past few years, developers have seen more and more autonomy and power. I can't imagine there's a way to avoid walking some of that back (if it can be)
> As a member of upper management, how would you address this then?
By specifying what is and what isn't allowed wrt. user data in products. By ensuring it gets included in new employee training, and communicating that exposing the company to data-related risks is a serious, fireable offense. By having internal checks and audits that monitor data risk and keep it low. I.e. basically the same things you'd address risk of financial malfeasance.
> Move way from "devops" and back toward a world where there's a clear isolation between ops and development?
It's not really about "devops" vs. dev/ops separation - it's about not moving fast and breaking other people's things. You can solve that with good professional practices, but there needs to be an incentive to adopt them (as opposed to the existing incentives to ignore them, in pursue of short-term profit).
Hard to show it was management's fault, and not the result of a developer who really didn't have the AWS skills (though that's probably still the fault of management, for not verifying skillsets before hiring or giving AWS keys)
Everything we know about iteration cycles, quick access to devops resources, etc, will change when prison time becomes an option.