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
(Score: 5, Interesting) by Aiwendil on Wednesday June 03 2015, @01:35PM
As the article points out NASA has actually solved the issue of coding high-reliability software - keep coders away from it and hand it to engineers.
To elaborate a bit this all basically comes down to training - most coders learn "if it works - ship it" while engineers basically get taught to think "how will this fail?", this simple little thing is what makes all the difference.
Don't get me wrong; there are good enough coders and there are crappy engineers but if you pick people at random from the different fields you are a lot more likely to get safer software (albeit at a slower pace of development) from the engineers.
I actually recommend it you coders out there to just sit in at a session when engineers code (or when they are taught how to code), the approach is quite different (and the tools they find easy to use will be _hard_ for you and vice versa). I have a nagging suspicion that this also is the reason for why almost all of the "legendary coders" comes from the era when computing still was in the domains of math and engineering.
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @02:51AM
Yep, for my tiny company engineers that have figured out how to program are the way to go. A few times I've hired "programmers" and they were hopeless at writing the custom engineering analysis software that we use in-house (and occasionally sell/license to others), even if we produced detailed specifications for the program. My best guy writes small chunks of code and exhaustively tests each chunk separately, then when he assembles the whole project it usually just works.
Where we suffer is when we need to do something that we call "computer science stuff" -- like multi language interfacing, for one example. Another example is making small programs run quickly for real time operation, in this case we have called in outside expertise.
(Score: 2) by fadrian on Friday June 05 2015, @01:13PM
That's simple stuff, man. Been doing it since the late 1970's. But then, I was trained as an Engineer, not as a programmer.
That is all.