SoylentNews is people
SoylentNews
Your average scripter likely isn't writing a whole lot of proofs or going through the rigors of formal program verification, generally. Which is fine because your average scripter also isn't writing software for jet airliners or nuclear power plants or robotic surgeons. But somebody is—and the odds are pretty good that your life has been in their hands very recently. How do you know they're not a complete hack ?
Well, you don't really. Which prompts the question: How is this sort of code tested? It was a short blog post written by Gene Spafford, a professor of computer science at Purdue University, that inspired this particular asking of the question.
http://motherboard.vice.com/read/how-is-critical-life-or-death-software-tested
[Related]: They Write the Right Stuff by Charles Fishman at Fast Company
Original Submission
(Score: 3, Informative) by Ox0000 on Wednesday June 03 2015, @03:24PM
It's tested just like everything else. What they don't catch by testing, they catch and mitigate for by redundancy.
Here's a true story:
I once worked on a product that was being deployed in an early adoption program at a large air plane manufacturer. Every so often we would give them a new version of the product, point them to known issues and ask them to find new issues. After two or three rounds of this, I got curious and asked my guy the following question: "When we ship the final version of this product, we know - we KNOW - that there will still be bugs in it and still we ship the product. But that's ok because this isn't mission critical stuff. Even if something goes horribly wrong, lives aren't at stake. But you guys, you guys build planes. If you guys make mistakes the way we do, people could die. Planes could be falling out of the sky. How do you guys manage to ship software without bugs?"
His Answer: "We don't. We have just as many bugs and equally severe bugs as you guys. But we build in redundancy. Every piece of software is made in triplet by three different teams that never talk to one another. On every plane, we have two separate Windows 2003 Servers running these different copies. Only if all the different copies of the software agrees with a majority of votes is when a decision is acted upon. And that third copy made by team 3: well, because we don't trust any of those Win2003 machines, we have also have a Linux machine that's running copy number three. We make up for bugs with redundancy!"
(Score: 2, Interesting) by Qlaras on Wednesday June 03 2015, @06:22PM
If it really matters, the company buying the product coordinates what languages & compilers each is using, and forbids any two from using the same programming language or compiler, too.
(Folks I know have worked in/on Avionics Software Engineering)
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @12:57AM
It still could go wrong without real world testing. Just hope they didn't all read the old paper and missed the new corrected one that has x/(n-1) rather than x/n. I assume in this case they always compare the expectations to real data in as many conditions as feasible though.