
A Look into NASA’s Coding Philosophy - tanu057
https://medium.com/@abnercoimbre/a-look-into-nasas-coding-philosophy-b747957c7f8a
======
mcguire
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.

~~~
ryanisnan
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.

~~~
mcguire
According to [https://www.fastcompany.com/28121/they-write-right-
stuff](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.

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

~~~
throwaway200610
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.

------
hackermailman
The CS:App book he mentioned has lectures too if you click on 'old
video(2015)'
[https://www.cs.cmu.edu/~213/schedule.html](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.

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

~~~
mcguire
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.

