Saying that an event was someone's ("the software developer's") fault isn't helpful. I'd even say it's harmful. We shouldn't be looking at individuals, but processes. Were there requirements for confirmation? If not, why? If so, were they implemented? How did this get past various reviews of requirements, designs (software and UI), and implementation? Was this raised as a concern early? These are the types of questions we should be asking. We shouldn't be using words like "fault" and "blame".
Per devops practices: "blame is a useless emotion that has no place in business"
I've never heard it in the context of DevOps, but in various Lean methodologies there's a similar idea. Blame and finger-pointing hinders continuous improvement.
Nothing wrong with borrowing good ideas :)
This cannot be emphasized enough.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.