A Look into NASA’s Coding Philosophy • Hacker News Board

Re: A Look into NASA’s Coding Philosophy

#21

Post by mcguire » Sun, Jul 30, 2017, 4:33 PM UTC

lisper wrote: 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 an aside, is JPL really NASA? Whatever happened with the lawsuit about HSPD-12 badges?

Re: A Look into NASA’s Coding Philosophy

#22

Post by throwaway12017 » Sun, Jul 30, 2017, 4:41 PM UTC

mcguire wrote: post #20

lisper wrote: 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…

I will copy and paste my reply from your last thread:

NASA, like many large organizations known for prestigious accomplishments, can struggle to meet the needs of those doing the enterprise work (like internal HR apps as you mentioned). Especially in a place like the government, people's ego's feel small, and they try to compensate by making their projects bigger, grander, and overstated. This just results in bloat, too much talking, and BS as you mentioned.

I'm sorry you had that experience. If you ever consider coming back, I'd recommend getting involved with something more directly related to space applications.

Re: A Look into NASA’s Coding Philosophy

#23

Post by mcguire » Sun, Jul 30, 2017, 4:41 PM UTC

dogma1138 wrote: post #7

lisper wrote: 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'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…

I'm not sure about that. I worked at MSFC before and after Constellation was canceled and I'm not sure the perception isn't due to believing their own propaganda. From a short distance outside, it didn't seem to be running very well.

(I have a friend and excoworker there who was an aerospace engineer, specifically concerning the design of solid rocket motors, who explained why Constellation was not going to match its hype: you can't add a segment to a SSRB to get a bigger motor; it's a complete redesign anyway.)

Re: A Look into NASA’s Coding Philosophy

#24

Post by throwaway12017 » Sun, Jul 30, 2017, 4:44 PM UTC

dogma1138 wrote: post #7

lisper wrote: 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'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.

Re: A Look into NASA’s Coding Philosophy

#25

Post by mcguire » Sun, Jul 30, 2017, 4:45 PM UTC

nickpsecurity wrote: post #16

alexanderdmitri wrote: post #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) 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…

DO-178C has a formal methods follow-on. I haven't seen it, though.

Re: A Look into NASA’s Coding Philosophy

#26

Post by [deleted] » Sun, Jul 30, 2017, 4:48 PM UTC

mcguire wrote: post #20

lisper wrote: 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…

[deleted]

Re: A Look into NASA’s Coding Philosophy

#27

Post by mcguire » Sun, Jul 30, 2017, 4:48 PM UTC

bluedino wrote: post #2

I'd like to see how this compares to, SpaceX for example

The last I heard, from outside the loop, there was considerable concern about how they were going to get man rated.

Re: A Look into NASA’s Coding Philosophy

#28

Post by elteto » Sun, Jul 30, 2017, 4:57 PM UTC

brianwawok wrote: post #18

dsfyu404ed wrote: post #9

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#...

The software team did an AMA on reddit a while back: https://www.reddit.com/r/IAmA/comments/1853ap/we_are_spacex_...

Basically it's C/C++ (as expected) for critical stuff, like the rocket or dragon, and C# for all enterprise systems. Plus an assorted set of other languages/technologies depending on team and project.

Re: A Look into NASA’s Coding Philosophy

#29

Post by lisper » Sun, Jul 30, 2017, 5:08 PM UTC

mcguire wrote: post #21

lisper wrote: 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 an aside, is JPL really NASA? Whatever happened with the lawsuit about HSPD-12 badges?

JPL's status is unique. It is technically an FFRDC (federall-funded research and development center) whose money comes from NASA. It is considered a NASA center, but it is unique among NASA centers in that its employees are Caltech employees, not federal government employees. That's why I added the prominent disclaimer. Whether or not it's "really" NASA is somewhat in the eye of the beholder. But they are definitely not a private enterprise like Space-X.

Re: A Look into NASA’s Coding Philosophy

#30

Post by brudgers » Sun, Jul 30, 2017, 5:16 PM UTC

lisper wrote: 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…

To me, the point of career comparison is probably more for new programmers (e.g. assigning a mentor) rather than long term...though for a US Federal government job, fifteen years in not particularly long term. I mean the experience you describe would not be a surprising description of Google or Apple or IBM. Nor would it be surprisingly applied to the US Park Service or Harvard. Those features are applicable to pretty much every large institution.

Early in a career, can be a good time to try out large institutions because large institutions tend to have explicit structures for on-the-job training and career development. Early in a career is also a good time for some people to decide "big companies ain't for me" and for other people to decide "this is a good fit." Over time people in the startup ecosystem often become just as cynical as career government employees. I think it's more a function of age and experience and personality than anything else. Bright eyed and bushy tailed doesn't go with gray hair.