I am very eager to study best practices when it comes to space hardening. For instance, I've read (though I can't find the article any longer) that some core parts of the Mars rovers did not use dynamic memory allocation, in fact it was forbidden. I've also read that old fashioned core memory may be preferable in space. 

I was looking at some of the projects associated with the Google Lunar Challenge and wondering what it would feel like to get code on the moon, or even just into space. I know that space hardened boards offer some sanity in such a harsh environment, however I'm wondering (as a C programmer) how I would need to adjust my thinking and code if I was writing something that would run in space?

I think the next few years might show more growth in private space companies, I'd really like to at least be somewhat knowledgeable regarding best practices.

What happens to a program if radiation, cold or heat bombards a board that sustained damage to its insulation? I think the goal is keeping humans inside of a space craft (as far as fixing or swapping stuff) and avoiding missions to fix things.

Furthermore, if the board maintains some critical system, early warnings seem paramount.

How does one gain experience in this through testing and trial & error (barring the launch of your own personal satellite?)

Space software is not arcane magic.  You are still using 0's and 1's, not 1's and 3's. So there’s probably no wow factor involved in describing what goes into developing software.

Some slight differences that come to mind at the moment are:


Extremely process oriented.
Space software will always have both software and hardware watchdog timers.
Every space system I’ve worked on was a hard real-time system.
You simulate (to great accuracy) every external actor to the system.  This usually involves building (sometimes really expensive) custom hardware that is used solely for testing.
You spend enormous effort and expense doing formal testing.
The customer (usually JPL) is extremely involved in the test process.
You generally are using old and known compilers and development environments, rather than the new ones.
Code reviews, code reviews and code reviews.
You better be very comfortable switching between the hardware and software worlds. You don’t have to know how to design the hardware but you have to know how it works.
Extensive use of test equipment, like oscilloscopes, logic analyzers, synthesizers and spectrum analyzers.
At least 3 locations for storing the application program. The default is burned in ROM. This will never change. The other 2 are for the current version and the next/last version.
Failure analysis (MTBF) is really important. 
Redundant systems and failover plans for the critical components.

