My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that.
Other stakeholders typically don't apply such caution.
Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
Yes, but the end users are not (yet) code, they are humans. In order to fix the data in the system, the organization will have to place a human behind the keyboard with the authority and ability to change the data from incorrect to correct.
> will have to place a human behind the keyboard with the authority [...] to change the data from incorrect to correct.
Whether such a person has such a permission in the system or whether the permission system of the software can actually model this is a work process that has been turned into code.
Other stakeholders typically don't apply such caution.