This weekend, we were celebrating the 50th anniversary of the moon landing. Inspired by the moment, we've plunged ourselves into studying the greatest milestones of space exploration and the brilliant minds standing behind them. Each successful landing, colorful photo of a distant galaxy, and radio signal sent from light hours away is a result of many years' of work on the part of scientists and engineers who were, and remain, pioneers in their field.
As a software development company, we simply could not prevent ourselves from studying the work of our colleagues. We've explored the code powering the first manned lunar mission, the development rules for building Martian rovers, and just how far-reaching assembly languages can be.
Now, we're sharing our findings with you.
BURN_BABY_BURN: Code that took us to the Moon
NASA’s Apollo 11 mission was launched in 1969 - literally pre-historic time for developers working with UNIX-like systems (well, almost all developers). But the most thrilling thing here is that we have free access to the source code for the Apollo 11 Guidance Computer (AGC) and the command and lunar modules on GitHub.
Thanks to the Virtual AGC and MIT Museum initiative, everyone can now explore the original lines that flew us to the moon. Those who are especially excited about coding for space can even compile them using the emulation of Apollo's onboard guidance computer.
It's worth mentioning that the language in which the code was written is hardly recognizable to modern engineers, but it is rather readable because Margaret Hamilton and her team at MIT added many comments to explain each other (and us) what each line is for. And yes, they named one of the files BURN_BABY_BURN–MASTER_IGNITION_ROUTINE. Here's an excerpt from it:
A deeper look can not only give you an idea of what was going on in the program but also what their work was like. You can clearly imagine their thoughts when typing this:
The total weight of the whole program is slightly bigger than 2MB; the screenshots we’ve made for this article are almost the same weight! But isn't it fascinating that such a tiny piece of code could take us so far?
Well, there was a checklist error that had almost prevented the lunar module from landing. But that's another story. This one is about people who had no Stack Overflow to search for help, about times when common software development and design principles were in their infancy, and about the “pocket calculator” that made it possible for people to walk the moon.
Power of 10 to power the one: Coding for Mars
Our developers can spend hours arguing about which programming language is the most popular on Earth, but when it comes to Mars, the answer is clear – it's C. Most of the software on Curiosity, the NASA rover operating on the planet's surface, is built in it (it was 2,5 million lines in 2012 and should be much more as of today). It also has over 1 million lines of Java and C++ code that are responsible for driving the rover and controlling its robotic arm.
But the most curious thing about Curiosity code is HOW it was written.
Shortly after heading JPL’s Laboratory for Reliable Software (LARS), Dr. Holzmann noticed that developers didn't follow most of the rules set in Coding Standards. On top of that, every mission had its own standard. As a result, you could get conflicting numbers when running the same code on different environments.
Dr. Holzmann spent endless hours asking his programmers only one question:
“If you could pick 10 rules to follow and ignore hundreds of others, what 10 rules would they be?”
Their answers formed the "Power of Ten" – a set of risk-based coding rules in which every rule came from a real-life accident or failure caused by its violation.
These rules are as follows:
- Avoid complex flow constructs, such as goto and recursion.
- All loops must have fixed bounds. This prevents runaway code.
- Avoid heap memory allocation.
- Restrict functions to a single printed page.
- Use a minimum of two runtime assertions per function.
- Restrict the scope of data to the smallest possible.
- Check the return value of all non-void functions, or cast to void to indicate the return value is useless.
- Use the preprocessor sparingly.
- Limit pointer use to a single dereference, and do not use function pointers.
- Compile with all possible warnings active; all warnings should then be addressed before release of the software.
You can find the detailed and comprehensive explanation of all 10 rules in Holzmann's article "The Power of 10: Rules for Developing Safety-Critical Code" published in the June 2006 issue of IEEE's Computer magazine.
Based on these 10 principles, the coding standard for Curiosity's software was developed. It includes 4 levels of compliance each containing its own set of rules. Check them out here if you want to learn what it is like to code the NASA way.
The best languages to get out of the system
If you think that assembly languages won't take you far these days, think again. Even though Fortran, Cobol and Algol sound like witty names for dinosaurs, they have the potential to become truly interstellar (even without black holes and bookshelf universes).
The Voyager mission was launched in 1977. Both probes have already left the heliosphere, and everyone from the original team has retired, but the project is still considered to be in its middle ages; it is planned to last until the late 2020s or even longer.
However, coding for the Voyagers is not only the way to send your lines out of the Solar system but also to invite someone from outside in. Both spacecrafts carry identical golden plaques with images of Earth and sound recordings – a kind of time capsule or “message in a bottle” for extraterrestrial lifeforms.
However, to actually see this content, our alien friends (or foes) must also think like programmers. The cover diagram with the instructions for playing the records, as well as locating the solar system, is encoded in binary.
Here's the explanation of each element:
You can also explore the content of the Golden Record on NASA's website here. May it be your dose of inspiration today.
These examples give us a chance to observe technological progress from another angle. They show how novel and pioneering 40-year-old technologies can be, how the brilliance of the human mind can flawlessly rulespacecrafts with only 2 megabytes of code, and how the right question asked to the right people brings solutions to the next level.
We hope you enjoyed reading this article as much as we did writing it. To close, a short quote from one of the Apollo engineers: