You might think the code powering humanity’s most distant spacecraft would be cutting-edge, but the reality is quite the opposite. The Voyager 1 and Voyager 2 probes, now traveling through interstellar space, still run on a Voyager programming language that was cutting-edge in the early 1970s: a custom assembly language written for purpose-built General Electric interrupt-driven processors. With total onboard memory sitting at roughly 64 to 70 kilobytes — less than a single modern email attachment — these spacecraft are a testament to lean, reliable engineering. The catch? Much of the original documentation from the 1970s and 1980s was printed on paper and lost during office moves, making the codebase something of a historical artifact. The current flight team at JPL is small, and the underlying difficulty isn’t just nostalgia: it’s finding engineers fluent in assembly on custom hardware who are willing to commit to a mission with a defined endpoint. Suzy Dodd, who was just 16 when Voyager launched, started working on the project in 1984 and became its project manager in 2010, embodying the deep institutional knowledge required to keep these twin explorers talking.
The Unique Computer Architecture of the Voyager Spacecraft
That level of expertise is necessary because the onboard systems rely on technology that predates the personal computer revolution. Each Voyager carries three independent computer systems, all running on a custom General Electric processor that few modern engineers have ever seen. This unique architecture defines the Voyager programming language still in use today.
Three Specialized Systems
The three onboard computers each handle a distinct set of responsibilities. The Computer Command Subsystem manages command sequencing and execution, acting as the brain that interprets instructions from Earth. The Attitude and Articulation Control Subsystem keeps the spacecraft oriented correctly, controlling thrusters and the scan platform that holds science instruments. The Flight Data Subsystem handles data collection, formatting, and transmission back to NASA. Together, these three systems coordinate everything from navigation to science experiments, with no backup or redundancy between them — each must operate flawlessly.
All of this runs on roughly 64 to 70 kilobytes of total onboard memory. For perspective, that is less memory than a single low-resolution image on your phone today. The code is written in assembly language, tailored specifically to the General Electric interrupt-driven processor at the heart of each system. This Voyager programming language is so specialized that no standard debuggers or emulators exist for it. Engineers work directly with raw assembly instructions, relying on printouts and decades-old documentation to trace how each command will execute.
The Assembly Language That Runs the Show
The exact processor model and its instruction set architecture remain unspecified in open literature, adding to the challenge of maintaining the spacecraft. Because the hardware was custom-built for NASA in the early 1970s, no commercial equivalents exist. The interrupt-driven design means the processor reacts to events in real time rather than following a simple linear sequence — an approach ideal for the unpredictable conditions of deep space, but one that makes the Voyager programming language particularly difficult to work with by modern standards. The team still relies on original engineering notebooks and handwritten annotations to understand how each instruction affects the system, a painstaking process that keeps these twin explorers operational decades past their planned lifetimes.
The Lost Paper Trail and the Aging Workforce
That reliance on physical notebooks and handwritten notes hints at a larger challenge: much of the original material that explained the Voyager programming language simply no longer exists. The mission’s formal documentation from the 1970s and 1980s was almost entirely on paper, and it vanished during a series of office moves over the decades. Without that paper trail, the current team often has to reverse-engineer the logic behind certain commands, relying on institutional memory and whatever personal records survived.
Documentation Lost to Office Moves
When the Voyager team relocated between buildings at JPL, boxes of manuals, schematics, and code explanations were misplaced or discarded. This wasn’t negligence—it was standard practice at a time when missions were expected to end long before anyone worried about archiving. As a result, large gaps exist in the written knowledge of how the Voyager programming language was originally assembled. Engineers today frequently comb through surviving fragments, but many details remain undocumented.
The Last of the Original Engineers
The loss of paperwork is compounded by the loss of people. Larry Zottarelli, the last original Voyager engineer, retired in 2016 at age 80. His departure closed a direct link to the mission’s early design phase. The current JPL flight team is small, and while most members are not in their 80s, the expertise they possess is rare and hard to replace. Suzy Dodd was just 16 when Voyager launched; she joined the project in 1984 and became project manager in 2010. Her decades of experience show how deep the knowledge runs—but also how limited the pool of veterans has become. Each retirement chips away at the living memory of the Voyager programming language, making every software patch a high-stakes exercise in preservation.
The Struggle to Maintain an Obsolete Codebase
This high-stakes environment is partly due to a pivotal moment in the mission’s history. After Voyager 2’s closest approach to Neptune in August 1989, the flight software was updated for autonomy. The primary planetary tour was complete, and the spacecraft needed to manage itself better as it headed into interstellar space. This necessary autonomy update cemented the codebase as it is today, making every subsequent modification a delicate operation on a system never designed for easy updating.
The 2015 Hiring Search – A Sign of the Times
So, who do you call when you need to patch this decades-old code? The underlying difficulty is finding engineers fluent in assembly on custom hardware who are willing to work on a mission with a defined endpoint. A notable 2015 hiring search made this struggle public. NASA wasn’t just looking for any assembly programmer; they needed someone fluent in the Voyager programming language and its unique architecture. The pool of qualified candidates is extremely small, and it gets smaller every year.
Why Modern Engineers Struggle with Voyager’s Code
Even if you manage to find the right talent, they face a development environment stuck in the 1970s. Modern comforts like advanced assembly language debuggers and emulators are largely absent. Instead, engineers must rely on original printed documentation, handwritten notes, and their collective memory. There is no easy way to simulate a patch before it is sent. Every line of code must be mentally traced, checked, and double-checked against a shrinking archive of institutional knowledge, because when you are working with a spacecraft billions of miles away, there is no room for error.
The Future of Voyager and Its Code
That painstaking care extends beyond just debugging. The real challenge for the Voyager team is a ticking clock you can’t patch. The twin spacecraft are powered by radioisotope thermoelectric generators, which convert heat from decaying plutonium into electricity. These generators lose about four watts of electrical output every year. That might not sound like much, but it forces the team to make hard choices about which instruments stay on.
Gradual Power Decline
As the power budget shrinks, engineers have already begun turning off non-essential heaters and instruments. Every watt saved means another year or two of science data from interstellar space. The process is methodical: the team prioritizes the instruments that return the most valuable engineering data, then switches off the rest. It’s a slow, calculated shutdown that has been happening for years and will continue until nothing is left but the bare essentials—the transmitters and the computers running that old Voyager programming language.
You can read more on this topic in Jason Butcher: How Ecosystem Intelligence May Complement VC.
When Will the Last Data Arrive?
Right now, engineering data could still return for several more years. But the mission will eventually end, probably when the power drops too low to keep the radio alive. The code itself will not be updated further. The focus is purely on maintaining existing functionality, not adding new features. Every line of that Voyager programming language has already been written, vetted, and locked in. The team’s job is to make sure it keeps running, even as the spacecraft grows colder and quieter. There is a somber efficiency to it: you are not building for the future; you are squeezing every last bit of life out of a legacy that has already exceeded every expectation.
Voyager 1 vs. Voyager 2: Differences in Computer Systems and Status
So you know the Voyager programming language keeps both spacecraft running, but they aren’t mirror images of each other. When you look under the hood, the hardware is identical—each Voyager carries three computer systems: the Computer Command Subsystem, the Attitude and Articulation Control Subsystem, and the Flight Data Subsystem. Yet their software histories and current conditions have diverged over decades of flight.
Similar Hardware, Different Paths
Both Voyagers launched with the same three-computer architecture and roughly 64 to 70 kilobytes of onboard memory. That shared foundation is a big reason why the Voyager programming language remains viable for both—the code just needs to talk to the same hardware. But their trajectories sent them on very different missions. Voyager 1 took a faster, more direct route past Jupiter and Saturn, while Voyager 2 visited Uranus and Neptune as well. This difference in flight paths meant their software evolved on separate schedules.
Voyager 2’s Critical Software Update
The most significant software difference came after Voyager 2’s closest approach to Neptune in August 1989. Engineers uploaded a major autonomy update to the flight software—a practical step that let the spacecraft make more decisions on its own. This was crucial because after the Neptune flyby, the spacecraft would become harder to communicate with as it traveled farther away. Voyager 1, having taken a different trajectory, never received that identical revision. Its software stayed closer to the original configuration, though it has seen smaller patches over the years.
- Computer status today: Both spacecraft’s computer systems are still functional, but their power budgets are slowly shrinking. Voyager 1 and Voyager 2 operate with slightly different power reserves, which affects how many instruments they can keep running at once.
- Software differences: The autonomy update on Voyager 2 gives it a bit more self-sufficiency, meaning it can handle certain anomalies without waiting for commands from Earth. Voyager 1’s older approach requires more ground intervention.
- Current status: Both are now in interstellar space, sending back data on plasma waves and magnetic fields. Their computer systems are holding up remarkably well, though engineers must carefully manage power to keep them alive.
So even with identical hardware and the same Voyager programming language, the two spacecraft have grown distinct over time. One got a smarter brain after a historic flyby; the other kept its original instincts. Both are still ticking, each with its own quirks and capabilities.
Frequently Asked Questions
How does NASA maintain Voyager’s code without hiring new engineers?
NASA relies on a small team of veteran engineers who have worked on Voyager for decades. They use the original assembly language—the Voyager programming language—to write updates and patches. New hires are rare because the language is obscure and requires years of hands-on experience to master.
Is it true that nobody alive can read Voyager’s code?
That’s a myth. While the Voyager programming language is a specialized assembly language from the 1970s, a handful of engineers still understand it. However, the knowledge is concentrated among a few aging experts, making it a practical challenge to maintain.
How much longer can the Voyager spacecraft keep operating?
The spacecraft are expected to continue sending data for several more years, but their power sources are gradually depleting. Engineers are making efficiency tweaks to extend their lifespan. The Voyager programming language remains essential for these adjustments.
