A Look into NASA’s Coding Philosophy | Hacker News Reader

A Look into NASA’s Coding Philosophy

medium.com

70 pointstanu05711 comments

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, no 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.

One further thing: I'm happy KSC still exists. When the shuttle program ended and Constellation dispersed, there were rumors that it was just going to dry up and blow away.

If I recall correctly, I've seen examples of the shuttle code printed out in a large volume (or volumes), where the code is documented line by line. In a way it is a testament to the relative immutability of the code and maturity of the work. I find it to be highly impressive and also suffocating at the same time.

In my experience, a lack of software quality is frequently introduced as a result of hurried time lines and limited resource allocation for quality and reliability. In other words, it appears more of an organizational, project management, or business failure.

According to https://www.fastcompany.com/28121/they-write-right-stuff in 1996:

* 420,000 LOC

* 260 people

* $35,000,000/year budget

* The Shuttle program ran from <1981 to 2011.

Assuming a constant budget, that's $1,050,000,000, total.

NASA, like many large organizations known for prestigious accomplishments, can struggle to meet the needs of those doing more run-of-the-mill things (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.

I worked at JPL in 2007 as an intern in the planetary sciences group. Dysfunctional software to say the least.

TL;DR ... if you hear the words 'IDL' Run!

All of the analysis was done using IDL (interactive data language) which was a bit similar to matlab ... but seemed to be written by non computer scientists ... a big issue I seem to remember is a bunch of weird state accruing in your program (lots of global variables). It was also used to construct GUIs (think java widgets).

What was icing on the cake though was the licensing. Each version had major incompatibilities, and the software was privatized a while back ... and sold back to NASA in the form of a network license (per version!) w only so many seats. So people's workflow would be to come into the office, see if they get a network license, and if not 'do other stuff' (unclear what that might be since the primary work was analysis). Then people were 'supposed to' give up their network licenses for lunch for a reshuffle. (So if you missed the morning window ... you'd work a bit into lunch to try and get a license for the afternoon). Craziness.

When I learned about all of this madness, I found a way to get a student license / compile what I needed for mac os. (Which was still recently *nix based at the time). As a result ... I actually got something done that summer, which seemed to amaze my PIs.

Since I surmounted one impossible feat, they asked for another. A 'competing' research group had data they wanted, but in an unknown proprietary binary format. They asked if I could crack it.

If the mountain of evidence hadn't convinced me before then, that really convinced me that these folks were really getting hindered by their use of technology (and bureacracy! and the political forces being grant writing!)

The thing that tickled me about that ask was they didn't understand how difficult it could be. And the thing that made me giggle was that it seemed like the cherry on top was there was likely to be a different 'endian-ness' btw their sparc servers and my mac.

Oh!

And heaven help the poor soul who was 'the IDL person' in the department. They never made eye contact in the cafeteria and seemed to eat really quickly. Everyone wanted some of his time. I ran across several heavily curse laden comments in the codebase from this person. That was probably their only salve. Also made me giggle though ... they were funny ... and probably on every person's computer in the dept though I doubt any of them had read the code enough to spot them.

I agree IDL is a poor tool. However, it is used widely across universities and research laboratories for space science and earths science and this is not problem exclusive to NASA. Yes, many people use Python, R, or Julia (we use Python in our lab at NASA) but there are people in science who get stuck in their old ways.

That said, this article reads like he's from a software engineering branch, not a science group.

The CS:App book he mentioned has lectures too if you click on 'old video(2015)' https://www.cs.cmu.edu/~213/schedule.html the Bomb Lab, and Attack lab are avail on the book's site in the student section without answers, but quick googling reveals many stackexchange answers if you can't figure something out.

Why would any NASA information be SBU (Sensitive but unclassified)?

SBU is the default classification, much like most proprietary software developed in industry is "for internal use only".

Some of it actually needs to be; we worked with PII (Personally Identifiable Information) a lot.

Aliens

Reply on news.ycombinator.com