A Look into NASA’s Coding Philosophy
mystudentvoices.com
A Look into NASA’s Coding Philosophy
1–10 of 57 posts
Re: A Look into NASA’s Coding Philosophy
#2I'd like to see how this compares to, SpaceX for example
Re: A Look into NASA’s Coding Philosophy
#3This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well as they did. I think the real secret at NASA is not that they are better at writing code, but that they write it slowly (development cycles are measured in years) and they test the living shit out of it. Then, once it's working, they don't change it except under extreme pressure. But while it's being developed it's just as much of a sausage factory as anything else.
Re: A Look into NASA’s Coding Philosophy
#4This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well…
Does that mean that as long as you test the shit out of it, it doesn't matter how it gets done?
Re: A Look into NASA’s Coding Philosophy
#5This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well…
Does that mean that as long as you test the shit out of it, it doesn't matter how it gets done?
That seems a reasonable position - yes.
Re: A Look into NASA’s Coding Philosophy
#6This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well…
Does that mean that as long as you test the shit out of it, it doesn't matter how it gets done?
Pretty sure that if repeated tests reveal aspects of the program to be deficient, the "how it was coded" will come out the proverbial wash.
Re: A Look into NASA’s Coding Philosophy
#7This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well…
I've also heard 1st hand stories and there have been multiple comments on HN regarding NASA.
The best I can tell is that the big difference in perception comes from people who worked on code for manned flights or anything that will interact with an actual human being vs non-manned and even non-mission critical code.
It seems that anything that will come close to a human is developed like it's the new arc of the covenant while for anything else it's YMMV based on the project and the team.
Re: A Look into NASA’s Coding Philosophy
#8Earlier quoted context omitted.
Does that mean that as long as you test the shit out of it, it doesn't matter how it gets done?
That seems a reasonable position - yes.
Reasonable if you ignore maintainability and standards compliance.
Not a coder, but if you used an idiom that worked because of a compiler quirk then that could lead to problems down the line but related to maintenance per se, hence why I added the second part.
Re: A Look into NASA’s Coding Philosophy
#9I'd like to see how this compares to, SpaceX for example
When it comes to physical components SpaceX has a habit of selecting an off the shelf component and asking the vendor if they can get a modified version that includes some changes that make it capable of living in their application.
That's great for reducing cost (or increasing quality or buying time, they're all related) but in the long term it often leads to spaghetti.
Considering the time pressure they're perpetually under and how Elon is known to run his organizations I would suspect their software products are no different.
Re: A Look into NASA’s Coding Philosophy
#10This article is very much at odds with my 15-year (1988-2000, 2001-2004) experience writing software at NASA (albeit at JPL, which is to say the unmanned space program, but still NASA). In my experience there was just as much politics, marketing hype, and general bullshit as I've seen in the commercial world. It was actually pretty amazing to me some times that things worked at all, let alone that they worked as well…
The author is young, and has been there for 3 years. I'm guessing this is anecdotal, and he happens to have had a good experience. Always possible things have improved though?