Programming

Edit: see my response, realised the comment was about engineering accountability which I 100% agree with, leaving my original post untouched aside from a typo that's annoying me.

I respectfully disagree coming from a reliability POV, you won't address culture or processes that enable a person to make a mistake. With the exception of malice or negligence, no one does something like this in a vacuum; insufficient or incorrect training, unreasonable pressure, poorly designed processes, a culture that enables actions that lead to failure.

Example I recall from when I worked manufacturing, operator runs a piece of equipment that joins pieces together in manual rather than automatic, failed to return it to a ready flag and caused a line stop. Yeah, operator did something outside of process and caused an issue, clear cut right? Send them home? That was a symptom, not a cause, the operator ran in manual because the auto cycle time was borderline causing linestops, especially on the material being run. The operator was also using manual as there were some location sensors that had issues with that material and there was incoming quality issues, so running manually, while not standard procedure, was a work around to handle processing issues, we also found that culturally, a lot of the operators did not trust the auto cycles and would often override. The operator was unlucky, if we just put all the "accountability" on them we'd never have started projects to improve reliability at that location and change the automation to flick over that flag the operator forgot about if conditions were met regardless.

Accountability is important, but it needs to be applied where appropriate, if someone is being negligent or malicious, yeah there's consequences, but it's limiting to focus on that only. You can implement what you suggest that the devs get accountability for any failure so they're "empowered", but if your culture doesn't enable them to say no or make them feel comfortable to do so, you're not doing anything that will actually prevent an issue in the future.

Besides, I'd almost consider it a PPE control and those are on the bottom of the controls hierarchy with administrative just above it, yes I'm applying oh&s to software because risk is risk conceptually, automated tests, multi phase approvals etc. All of those are better controls than relying on a single developer saying no.