From a programmer point of view, the ideal is a language that doesn't let you make simple mistakes like the goto fail; bug.
From an engineering point of view, it's having the processes in place to make sure that when such bugs inevitably happen, they don't end up in the final product.
The reality is having both of these things would be ideal.
Yes! It's about creating systems to reduce defects.
Processes are systems; language and its constructs are systems. Both may contain methods to control variation and improve quality.
The point is to control variation. Nothing more. Any complete system that connects what we intend, with we tell the computer to do, with what the computer actually does, is good. We need to move in that direction.
Blaming an individual is pointless. Never was there a more consistent or uncontrollable source of variation than the human. We need to surround ourselves with systems that enforce quality, and that do not let us choose to introduce defects.
For this to take place, we have to first and foremost understand that this is the goal. That quality comes from the system and not the individual. Until then we will see only human error translated to computer error continually and unstoppably.
As the article said. Disasters have more than one cause, almost without exception.
Then, quality minded people just know that they must correct ALL the causes, because they may lead to another disaster in another combination (and that includes dealing with human errors). People without the quality mindset often decide that it's enough to fix ANY of the causes, because that'll avoid a repetition of the disaster.
From a programmer point of view, the ideal is a language that doesn't let you make simple mistakes like the goto fail; bug.
From an engineering point of view, it's having the processes in place to make sure that when such bugs inevitably happen, they don't end up in the final product.
The reality is having both of these things would be ideal.