You're correct to point out that the coding style isn't to blame for the software fault. And IMO The last paragraph of the article hints at the most probable fundamental cause.

But I just don't buy that this was not a software fault. It clearly was a case of a faulty software specification.

> The problem seems to have been at a different level than coding.

This makes me queasy. Software engineers working on these sorts of systems -- -- or at least a few senior ones -- should understand enough of the domain to say "this spec is not adequate" or "bad things might happen under conditions xyz; what's the correct behavior in these cases?". And of course all software should notice and then degrade gracefully when assumptions are observably violated.

To absolve the software engineer of any responsibility for understanding the context surrounding his software is to wrongly assume there's not much to software engineering beyond programming to someone else's spec.