Live data from Hacker News

A Look into NASA’s Coding Philosophy

mystudentvoices.com

31–40 of 57 posts

Re: A Look into NASA’s Coding Philosophy

#31
post #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…

> NASA itself is a massively disfunctional organization, in my experience, and a failure to "cut through the bullshit" is a major reason why.

I completely agree with this, though I think it's important to note two things. First, despite the dysfunction, they do, more often than not, make things that work under extremely challenging conditions. And second, a lot of the dysfunction is not their fault, but is a consequence of the fact that they are a government agency and hence ultimately answerable to Congress. Not only that, but they are a government agency created to fight a (cold) war that ended almost thirty years ago so they have been rudderless for a long time. The fact that they've done anything other than suck up taxpayer dollars is a testament to the incredible skill, both technical and political, of many of the people in the agency. Notwithstanding my vocal criticism of the organization, I have tremendous respect for many of the people who work there.

Re: A Look into NASA’s Coding Philosophy

#32
post #8

Earlier quoted context omitted.

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.

I was thinking in a historic archiving sort of situation, bringing to mind recent stories of NASA code being unearthed. Basically I was expecting "it passes all the current unit tests" to be an insufficient standard for NASA coding.

Re: A Look into NASA’s Coding Philosophy

#33
post #4
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…

Does that mean that as long as you test the shit out of it, it doesn't matter how it gets done?

No, it still matters. But exhaustive testing can produce reliable products from unreliable processes. The extreme example of this is evolution itself.

Re: A Look into NASA’s Coding Philosophy

#36

Earlier quoted context omitted.

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

NASA has a classification of software into class A, class B, class C, etc. Class A is human spaceflight, class B is critical non-human spaceflight, and the rest is non-critical software. The amount of process and oversight is highest at class A, and lowest at class E. If you are developing class E, you can do pretty much whatever you want and your team doesn't even need any training in software engineering.

This is completely true, in my experience.

If you want some fun, track down somebody working at the NASA Enterprise Applications Competency Center and ask them about the Office of Education software. (Me, I know nothing, through an exercise of good luck and skill. "No hablo ingles. Tengo hambre. Mucho muerte. ")

Re: A Look into NASA’s Coding Philosophy

#37

I always found this article(1) about writing code for NASA fascinating. I'm sure a lot has changed in the 20 years since it was written, but it's such a stark contrast to what I'm used to. (1) https://www.fastcompany.com/28121/they-write-right-stuff

20 years ago:

* 420,000 LOC

* 260 people

* $35,000,000 / year

Re: A Look into NASA’s Coding Philosophy

#38
post #37

I always found this article(1) about writing code for NASA fascinating. I'm sure a lot has changed in the 20 years since it was written, but it's such a stark contrast to what I'm used to. (1) https://www.fastcompany.com/28121/they-write-right-stuff

20 years ago: * 420,000 LOC * 260 people * $35,000,000 / year

There's something to be said about doing more with less.

Re: A Look into NASA’s Coding Philosophy

#39
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…

> ... they test the living shit out of it. Then, once it's working, they don't change it except under extreme pressure.

I wonder if self-driving car manufacturers will apply this same philosophy.

Re: A Look into NASA’s Coding Philosophy

#40

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…

Applied very narrowly to the right problem, maybe.

But I have also seen DO-178B to lead to a completely non-maintainable mess. That mess helps trace each statement to a requirement, but leads to code that is unreadable to anyone used to normal code.

It is not that "no extra code" and exactly meeting requirements is a bad model in itself. However writing code in a way that makes it convenient to prove the above encourages unnatural coding styles and programmatic contortions. YMMV however.

Post reply on HN