Live data from Hacker News

A Look into NASA’s Coding Philosophy

mystudentvoices.com

11–20 of 57 posts

Re: A Look into NASA’s Coding Philosophy

#11
post #8

Earlier quoted context omitted.

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.

In any mission critical situation the entire tool chain is just as locked down and controlled as the "source code," even down to the silicon.

Re: A Look into NASA’s Coding Philosophy

#12
post #3

This 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…

Not mentioned: Some software at NASA gets "human in the loop" testing. I work with GSFC, and that makes a lot of things difficult and very slow.

Re: A Look into NASA’s Coding Philosophy

#13
post #8

Earlier quoted context omitted.

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.

I doubt NASA would ever ever upgrade compilers on software once tested. If it is like a aviation, there might even be manual passes over the assembly code for further verification.

Re: A Look into NASA’s Coding Philosophy

#14
Here's a paper[1] for a space conference in Montreal written a few years ago on DO-178 standards and applying the FAA's certification process to space systems development (DO-178 sets the bar for "testing the shit" out of software, I've seen projects held up for years because it's like approaching a limit f(n) -> L (where f(n) is the software development cycle and L is getting a non-bought DER to sign off on it) proving your system to its requirements).

[1] http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_quer...

Re: A Look into NASA’s Coding Philosophy

#15
post #3

This 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 don't think you contradict each other. You just seem to focus on different sides of NASA development process.

Re: A Look into NASA’s Coding Philosophy

#16

Here's a paper[1] for a space conference in Montreal written a few years ago on DO-178 standards and applying the FAA's certification process to space systems development (DO-178 sets the bar for "testing the shit" out of software, I've seen projects held up for years because it's like approaching a limit f(n) -> L (where f(n) is the software development cycle and L is getting a non-bought DER to sign off on it) prov…

DO-178B was one of best things to happen in software assurance. It was a non-prescriptive method of certification that forced precise requirements, design, and code with reviews of each and tracability between them. The high cost of certification and certification failure led to a booming ecosystem of supporting tools (esp static analysis or runtimes) and pre-made components (esp RTOS's & middleware). Some companies even specialized in handling the administrative overhead. The result was that certified systems usually had very, high quality. Meanwhile, there were people arguing on HN and other places about whether a certification could ever be useful for software.

Anyone reading the above paper should skip to the summary to get a high-level view of the overhead and resulting benefits. The author of the paper agrees with me that the certification is beneficial. The gist is you keep things simple, think about everything in lifecycle, test everything in lifecycle, throw every analysis tool you can at the design or code, esp take your time to develop the thing, and document all of this in a way where any aspect is easy to verify by a 3rd party. That's how high-assurance systems are done. They usually work, too. Some work for a long, long, long time. :)

Re: A Look into NASA’s Coding Philosophy

#17
post #3

This 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…

If a lot of process is applied to verify the robustness of the code, then to me the overall development process is not a sausage factory.

Re: A Look into NASA’s Coding Philosophy

#18
post #2

I'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 perpetua…

On that note, what language(s) are SpaceX, Tesla built on?

Job postings I see a mix of C# and golang. I cannot believe either a Model X or a rocket is rockin C#...

Re: A Look into NASA’s Coding Philosophy

#19

Earlier quoted context omitted.

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 perpetua…

On that note, what language(s) are SpaceX, Tesla built on? Job postings I see a mix of C# and golang. I cannot believe either a Model X or a rocket is rockin C#...

Probably not on the rocket itself, but C# is a very common language for ancillary testing tools in the industrial automation world. I wouldn't be surprised if a lot of their test infrastructure is written in C#.

Re: A Look into NASA’s Coding Philosophy

#20
post #3

This 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 I wrote when this showed up on proggit,

Not to put too fine a point on it, but I would be very skeptical about using NASA as a good example for much of anything, but especially software development.

My bonifides: I'm 49; have spent roughly 25 years as a systems programmer, systems administrator, and general bit wrangler; and I worked for 8 years at the Marshall Space Flight Center, specifically the NASA Enterprise Application Competency Center.^1 (And yes, that's a thing. Started as IFMP (Integrated(?) Financial Management(?) Program), and was IEMP (Integrated(?) Enterprise Management(?) Program) when I started.) If you're a NASA employee, you might recognize STaRs (I worked on the rewrite, post Perl 1 and Monster.com), NPROP/Equipment, or DSPL/Disposal. And IdMAX, which I noped out of shortly after moving to the project.^2

NASA itself is a massively disfunctional organization, in my experience, and a failure to "cut through the bullshit" is a major reason why. For software development specifically, while I didn't do anything with "man-rated" development or the other important bits, I have strong doubts that they are any better than other avionics, automotive, or other embedded development organizations.

There was no mentoring. People tried, it didn't go over well, usually with the mentees.

You have to trust each other's potential, because there is no damn chance of getting any two projects to agree on anything. What goes on in that other silo is their business, not yours.

I did say, "I don't understand." A lot. Frequently pronounced "WTF?"

The list of "unreliable sources of knowledge" looks rather like a checklist of how things got done.

^1 NEACC is also the acronym for the North-East Alabama Community College, which I find ironic for no good reason.

^2 Unfortunately, I don't have a picture of me looking arrogant. Sorry.

Post reply on HN