I implied in a previous blog that software engineering (any more than any other form of engineering) provides no guarantees regarding "correctness". No doubt some readers are horrified at such a suggestion, but that doesn't stop it being true. When an engineer signs off on any piece of construction, the engineer isn't guaranteeing that it is "correct" (e.g. the building won't fall down, the bridge won't collapse, the power station won't fail to deliver electricity), what the engineering is indicating is that the piece of construction has been built according to current agreed standards of engineering.
When an engineer signs off on some construction, he or she is putting their professional reputation on the line, at least. There is a story (probably apocryphal) that Napoleon would make his bridge engineers stand under the bridges they had built while his beloved artillery rolled over them. The theory being that the engineers would make sure the bridges wouldn't collapse if their lives were at stake. I imagine that today there are plenty of engineers who take a deep breath when they find themselves at the mercy of their own creation! This is as true of software engineers as anyone given the amount of software that controls much of what we deal with in the modern world. In some of these cases, someone does sign off on the software, but it is not the common case.
If there is a failure, the argument (and law suits) is not about whether the failure should or should not have occurred, the argument is about whether the construction followed good engineering practice. If the argument supports such was the case, then the engineer who signed off on it is probably in the clear (not that that will make the engineer feel any better about the situation). Another aspect of engineering is that when there is a failure, there is an attempt to discover the cause of the failure. What is learned an fed back into the profession in order to reduce the chance of that kind of failure happening again, and so generally improving the profession. Regrettably this almost never happens with software failures.
The goal of the professional engineer is to avoid the kind of failures we know how to prevent. The profession codifies best practice that, by whatever evidence (scientific, mathematical, or experience), is strongly believed to not lead to failures. Tragedies such as Cave Creek and the CTV building collapse provide sobering examples of what can happen when best practice isn't followed. Note that these were not examples that pushed the boundaries of current engineering understanding, such as the Tacoma Narrows Bridge, these were your bog standard building and viewing platform.
We regularly have failures (usually failure to deliver) of bog standard software systems (how is it that after all of these years we still cannot reliably build a payroll system?) No one signs off on them and no attempt is made to learn what exactly went wrong. I think as an engineering profession, we've got a long way to go.