Rocket Science

Space exploration and computers are inextricable. It is unthinkable, at least with our level of understanding, to imagine one without the other. It is no surprise that both grew together, mutually reinforcing one another, precisely at the same point in human history. Being the most complex undertaking ever attempted by Humanity, involving the juggling of so many balls in the air at once, computers became our allies to make space travel a reality.

Leaving aside the obvious risk of shipping humans inside tin cans traveling at supersonic speeds, the lives of astronauts and cosmonauts depend on solid software to understand what is going on. Or, at the very least, how far they are from Earth and how to come back. At the risk of stating the obvious, let us remind ourselves that this is still the only place we can inhabit in the known Universe, even if we are doing everything possible to render it as unlivable as possible.

Arguably, one of the most brilliant creations of George Lucas in his Star Wars universe is the idea of “Astromech droids”; small robots perfectly sized to fit ad hoc slots on spacecraft, able to communicate with the onboard computers, and acting as a required interface for the organic pilots at the helm starring in the films, human or not. So good are Astromech droids at their craft, that even C-3PO, supposedly “fluent in over six million forms of communication,” has trouble understanding the “strange dialect” used by the Millenium Falcon onboard computer during the most tense moments of The Empire Strikes Back. It raises the question of the effectiveness of the standards body in charge of that galaxy far, far away; are there no mandatory reviews to follow before takeoff? Ah right, the Falcon is a smuggling ship. Move on, there is nothing to see here.

Onboard computers that are difficult to communicate with are a staple in science fiction. Comes to mind the quintessential onboard computer, HAL 9000, who (who or which?) essentially interacted with humans in plain English. Such fluency does not prevent it from becoming a pain in the neck for Dave Bowman, but that is another story. Another classic example is the malfunctioning computers (and their hilarious interaction with crew members) in charge of “Thermostellar Triggering Devices” carried by the Dark Star ship in the underrated and excellent John Carpenter’s 1974 film of the same name. The M-5 computer featured in the 24th chapter of the second season of the original Star Trek series (1968) deserves another special mention.

How good the software used in space travel needs to be? The (almost obvious) answer shows up in a classic, memorable, and certainly recommendable 1996 article from Fast Company magazine (archive) whose title references an equally epic 1983 motion picture:

The right stuff is the software. The software gives the orders to gimbal the main engines, executing the dramatic belly roll the shuttle does soon after it clears the tower. The software throttles the engines to make sure the craft doesn’t accelerate too fast. It keeps track of where the shuttle is, orders the solid rocket boosters to fall away, makes minor course corrections, and after about 10 minutes, directs the shuttle into orbit more than 100 miles up. When the software is satisfied with the shuttle’s position in space, it orders the main engines to shut down — weightlessness begins and everything starts to float.

But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

We are in 2023, which means that the article above is 27 years old. Is it fair to compare your containerized Cloud Native or Android application to the software piloting the latest spaceship? (The Space Shuttle ended its career meanwhile, sadly.) One needs to make a fair comparison. A few months before the publication of this article in Fast Company, the Ariane 5 blew up because of a badly handled integer overflow exception. And three years later,

NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency’s team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday.

OK, OK, you might argue that the last one is not strictly speaking a software error; the actual issue was related to communication and quality management. Yes, but those are the hardest parts of software engineering. Any programmer can agree with this author that the simplest part of a project is actually pumping out the code on the IDE.

The aforementioned article on Fast Company contains other gems:

Software is everything. It also sucks.

“It’s like pre-Sumerian civilization,” says Brad Cox, who wrote the software for Steve Jobs NeXT computer and is a professor at George Mason University. “The way we build software is in the hunter-gatherer stage.”

John Munson, a software engineer and professor of computer science at the University of Idaho, is not quite so generous. “Cave art,” he says. “It’s primitive. We supposedly teach computer science. There’s no science here at all.”

The article explains the effectiveness of NASA-made software with four basic premises:

1. Planning. “Our requirements are almost pseudo-code.”
2. Teams. Composed of both coders and testers, the latter referred to as “verifiers” in the article.
3. Data. The two “enormous databases, encyclopedic in their comprehensiveness” mentioned in the text are just a source control system, and a bug tracker.
4. Culture. “You don’t get punished for making errors.”

Point 3 above is probably the only one that has been successfully implanted in our minds and industry since 1996. The other three items in the list are a work in progress, at best, or a glaring omission due to budgetary cuts, layoffs, or just the “Agile” word being hypocritically screamed at every meeting (particularly true for those arguments in favor of the first point above).

Page 193 of the July 1985 issue of BYTE Magazine (dedicated to space and astronomy subjects) contains another interesting article about how NASA prepared its missions in the first decade of the Space Shuttle program. In this case, including details about the programming language of choice for the Shuttle Imaging Radar-B (SIR-B) experiment:

Both the SIR-B mission-planning software and the real-time communications software were written primarily in FORTH. The off-the-shelf FORTH implementation (PC/FORTH by Laboratory Microsystems) included fast display graphics for the IBM PC, a standard PC-DOS file interface, and high-level support for the 8087 coprocessor. Again. speed. adaptability, and readily available support were major considerations in choosing the programming language.

The available choices in the programming languages market 38 years ago seem stunning by today’s standards. C++ was still virtually unknown outside Bell Labs, and Perl had not even been released yet.

Fast-forward to 2023, and NASA’s Spacecraft Software Engineering Branch keeps on crunching better software than any of us could imagine, and publishing a full catalog of software applications, often open source and ready to download and use in your own spacecraft. Not only that, but as this article hits the web, the 46-year-old Voyager 2 probe, at 20-something billion kilometers from Earth, just received a much hyped software patch. Meanwhile, some of us Earthlings have to reboot our computer twice just to print a document. Whatever.

NASA, who uses all kinds of computers, has adopted Linux as an operating system of choice, first on the International Space Station, and then as support for other missions, as a real-time OS, on Artemis’ flight simulators, and even on Mars. There are rumors that the CADRE rovers will run with Debian on our natural satellite. SpaceX took note, as we should all.

A quick glance at the frowning eyebrows and shrugs of the readers of this article indicates that no, we have not advanced much in the past 27 years. Paraphrasing Brad Cox, we are still in Precambrian times, with the added insult of evolving in an industry that finds periodic reinventions of the wheel not only palatable, but an actual Darwinian conditio sine qua non in our evolution towards the future.

Spoiler alert: it is not, and we keep shipping shitty software.

As a society, we could be producing much finer software if we stopped worshiping the wrong gods decade in, decade out. The solution is not Rust, yet another JavaScript framework, Kubernetes, or GitHub Copilot. The solution is not yet another IDE or yet another Agile retrospective (enough of it, already). And yes, it is a desirable goal for our civilization to crank out stable, fast, high-quality, maintainable software, not only for mission-critical stuff, but even for the most mundane of games. And doing so should not be considered a seemingly impossible task in the order of rocket science, but it could take a few cues from actual rocket scientists.

As programmers, we need to start giving a shit about our software and the way it impacts our modern world. We must stop conflating the creation of software as a simple way to becoming yet another billionaire, but to take our craft with the rigor it deserves, even if that means overcoming our aversion to writing and drafting a spec from time to time.

Or, to put it another way: we do not need hot stuff tonight, Donna; the right stuff will do just fine.

Cover photo by NASA on Unsplash.

Continue reading Margaret Hamilton or go back to Issue 063: Space. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!