Re:A Look into NASA’s Coding Philosophy
by throwaway200610 on Wednesday July 19, 2017 @07:07PM
(#14808770)
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.
Re:A Look into NASA’s Coding Philosophy
by ryanisnan on Wednesday July 19, 2017 @02:23PM
(#14806592)
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.
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.