Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by n1 on Wednesday June 03 2015, @09:48AM   Printer-friendly
from the wishful-thinking-and-faith dept.

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

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by Aiwendil on Wednesday June 03 2015, @01:35PM

    by Aiwendil (531) on Wednesday June 03 2015, @01:35PM (#191580) Journal

    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.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=2, Informative=1, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 0) by Anonymous Coward on Thursday June 04 2015, @02:51AM

    by Anonymous Coward on Thursday June 04 2015, @02:51AM (#191883)

    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

      by fadrian (3194) on Friday June 05 2015, @01:13PM (#192498) Homepage

      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.