Loading 2 Votes - +

Also worked at JSC

I worked at JSC as a contractor for 7 yrs on real-time fight control systems and mission control center code used around the world, on the shuttles and space station.

While I can’t comment specifically on the CRAP system or any other that I didn’t work, I can assure you that for the 4 systems on which I worked with teams of 3 to over 500 developers:
a) code maintainability was as a critical aspect
b) efficiency was an issue, almost always (imagine running on 15+ yr old hardware and still adding code to it with the old RAM still inside)
c) reformatting code just to make it pretty was against the coding standards. We didn’t touch a line if we didn’t have clear authority to change it for functional reasons. We did make it pretty while working on it, just not when checked in.
d) self documenting code is a good idea, provided the coders aren’t small minded and can step back and think like the next coder will. That is a rare skill, in my 20+ yrs of coding. Commenting based on what the next guy wants to know isn’t easy. Some compilers had stupid limitations on variable lengths.
e) nobody should be allowed to write new code until they’ve been a maintenance programmer for 2 years. You learn a ton on how not to code that way. It doesn’t really matter what language.
f) for systems that allowed dynamic memory allocation, a memory leak was considered a Sev 1 bug. Real-time FC systems don’t usually allow memory allocation.
g) unclear code comments were considered minor bugs, including spelling errors. Had to be corrected before the code was submitted.
h) every line of every program was reviewed by at least 2 other people who physically signed a piece of paper saying they didn’t find any errors. When you sign your name to a review and hand it in, you tend to actually perform a careful review. That paperwork with my signature can still be found, I’m certain.
i) if someone assigned to review design, code, or test work wasn’t ready, we held up the review until they were. PERIOD. If they didn’t consistently review and catch errors that other reviews found, they were encouraged to “find someplace else” to spend their days via peer pressure. This wasn’t needed very often. We all counted on each other to catch mistakes that could get people killed or destroy billion dollar vehicles.

For the GN&C software I developed, only 2 errors made it outside our group in over 5 years were attributed to me. I introduced many errors, but the team caught almost all of them. I caught my share of errors in other peoples’ code too. When I left that team, all 11 remaining developers introduced less than 1 error every 2 years combined.

Last I heard, a few of the guys now work at pace maker companies writing software. My mother has a pace maker and I’m very happy these guys probably ensured it works perfectly, EVER TIME.

Your Comment

What is OmniNerd?

Omninerd_icon Welcome! OmniNerd's content is generated by nerds like you. Learn more.

Voting Booth

Can Trump make America great again?

14 votes, 1 comment