Earlier quoted context omitted.
That seems a reasonable position - yes.
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.
A Look into NASA’s Coding Philosophy
11–20 of 57 posts
Re: A Look into NASA’s Coding Philosophy
#12This 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…
Re: A Look into NASA’s Coding Philosophy
#13Earlier quoted context omitted.
That seems a reasonable position - yes.
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.
Re: A Look into NASA’s Coding Philosophy
#14[1] http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_quer...
Re: A Look into NASA’s Coding Philosophy
#15This 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…
Re: A Look into NASA’s Coding Philosophy
#16Here'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…
Anyone reading the above paper should skip to the summary to get a high-level view of the overhead and resulting benefits. The author of the paper agrees with me that the certification is beneficial. The gist is you keep things simple, think about everything in lifecycle, test everything in lifecycle, throw every analysis tool you can at the design or code, esp take your time to develop the thing, and document all of this in a way where any aspect is easy to verify by a 3rd party. That's how high-assurance systems are done. They usually work, too. Some work for a long, long, long time. :)
Re: A Look into NASA’s Coding Philosophy
#17This 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…
Re: A Look into NASA’s Coding Philosophy
#18I'd like to see how this compares to, SpaceX for example
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…
Job postings I see a mix of C# and golang. I cannot believe either a Model X or a rocket is rockin C#...
Re: A Look into NASA’s Coding Philosophy
#19Earlier 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#...
Re: A Look into NASA’s Coding Philosophy
#20This 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…
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, not 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.