In most offices, old code is an annoyance. At NASA, old code can be a survival skill.

That sounds dramatic, but space has earned the right to be dramatic. When a spacecraft launched in the 1970s is still whispering home from interstellar space, nobody gets to sneer at “legacy systems” anymore. At that point, legacy is not a dirty word. It is the reason the mission is still alive.

That is why the idea of NASA needing a programmer fluent in 60-year-old languages is not some quirky retro joke for people who own punch cards as home decor. It is a real reflection of how long-lived missions work. Spacecraft outlast product cycles, operating systems, trendy frameworks, and entire generations of engineers. A mission that began when disco was young may still need support in an era of cloud computing and AI copilots. And when that happens, somebody has to understand the logic, assumptions, and language choices baked into those systems decades ago.

For NASA and the Jet Propulsion Laboratory, this is especially true for missions like Voyager, for deep-space navigation tools with roots in the late 1960s, and for scientific software built in FORTRAN, assembly, or other older languages that were designed for reliability, mathematical performance, and tight hardware limits. In other words, while the rest of the tech world is busy arguing over which JavaScript framework has the best vibes, NASA is busy asking a much harder question: who can safely touch code that still matters?

The headline sounds weird, but the problem is perfectly logical

The phrase “60-year-old languages” makes it sound as if NASA is rummaging through a software museum with a flashlight. In reality, the agency is dealing with a practical engineering truth: missions do not end when the launch livestream does. Some systems stay relevant for decades because the hardware is still operating, the scientific models still work, or the cost and risk of replacing validated software is simply too high.

That is why old languages never fully disappear in aerospace. FORTRAN, for example, has had an absurdly long life because it is exceptionally good at numerical and scientific computing. Assembly language, meanwhile, remains essential when engineers need intimate control over hardware behavior, memory locations, timing, or machine-specific instructions. HAL/S, another historical example, was closely associated with NASA flight software heritage during the Space Shuttle era. These are not “cute” technologies being kept around for nostalgia. They are tools that solved very hard problems, and in some cases, they still do.

NASA’s software history proves the point. Long before modern dev teams started saying things like “tech debt” with a dramatic sigh, NASA had already accumulated a deep stack of mission-critical software heritage. That heritage includes not only spacecraft code, but also navigation software, ground systems, simulation tools, data pipelines, and operational procedures built around older languages. Once a tool becomes trusted in a high-stakes environment, replacing it is never as simple as opening a new repo and writing “version 2.”

Which old languages are we talking about?

FORTRAN: the grandparent that still pays the bills

If one old language deserves a reserved parking space at NASA, it is FORTRAN. Born in the 1950s and still annoyingly useful, FORTRAN became foundational for scientific and engineering computing because it handled complex mathematics efficiently and predictably. That matters when your software is computing trajectories, analyzing sensor data, or simulating physical systems that are expensive to test in the real world for obvious reasons. Rockets are not ideal beta environments.

JPL’s own history shows how deeply FORTRAN was woven into mission work. For many years, NASA’s planetary missions were navigated with FORTRAN-based software that originated in the late 1960s and expanded over decades. That software was eventually modernized and succeeded by newer tools, but the important point is not that FORTRAN lasted a long time. The point is that it lasted because it worked, because it was trusted, and because whole mission operations grew around it.

Even better, FORTRAN is not just a fossil in a NASA display case. NASA’s software catalog still includes Fortran-focused tools such as parsers, template libraries, and unit-testing frameworks. That tells you something important: this is not just about reading ancient code like a software archaeologist in a windbreaker. NASA still supports workflows where Fortran knowledge is useful today.

Assembly: where the machine stops pretending

Assembly language is where programmers stop asking the computer politely and start speaking in its native accent. It is low-level, exacting, and deeply tied to specific hardware. For most modern developers, that sounds like a great way to spend a stressful weekend. For spacecraft engineers, it can be the difference between understanding a system and merely hoping for the best.

When you are dealing with old onboard computers, severe memory limits, or one-of-a-kind processors that are no longer manufactured, assembly matters because abstraction has limits. At some point, somebody has to know what lives where in memory, how instructions are sequenced, what a register is doing, and why a change that looks tiny on paper could have mission-wide consequences.

HAL/S, COBOL, and the rest of the old guard

NASA’s historical software records also highlight languages such as HAL/S and COBOL. In older agency documentation, COBOL, FORTRAN, and HAL/S were described as predominant high-order languages in NASA use. HAL/S, in particular, was linked to Space Shuttle flight software heritage. That does not mean NASA is trying to run the universe on a software retirement home. It means aerospace organizations keep the tools that match the system, the certification burden, and the mission lifecycle.

Voyager is the clearest example of why this matters

If you want one mission that explains the whole legacy-language issue without needing a PowerPoint, it is Voyager.

Voyager 1 and Voyager 2 launched in 1977. They were built with mid-1970s computing constraints, and yet they are still among the most extraordinary engineering achievements in human history. They are also the ultimate argument against the phrase “we’ll just rewrite it later.” Later has lasted almost half a century.

NASA has explained that Voyager’s onboard sequence storage is extremely limited by modern standards. The available memory for storing sequence instructions is tiny, which forces engineers to think with extreme discipline. There is no room for bloated logic, casual assumptions, or “we’ll clean that up in the next sprint.” Spacecraft do not care about your sprint. Spacecraft care about power, timing, memory, and not dying.

Then came the 2024 Voyager 1 issue. Engineers traced the problem to a failed chip storing part of the flight data subsystem’s memory, including some of the software code. They could not repair the chip directly, so they did something that sounds equal parts brilliant and terrifying: they moved the affected code into other parts of the memory, divided it into sections, adjusted it so the pieces would still function together, and updated references to the new locations. That is not generic software maintenance. That is surgery with oven mitts from billions of miles away.

This is where fluency in older languages and legacy architectures becomes priceless. The challenge is not only understanding syntax. It is understanding how an older system was designed to think. Engineers have to work within original constraints, interpret old documentation, reconstruct intent, and avoid breaking what they are trying to save. It is debugging, but with a round-trip communication delay so long it could make a saint start muttering at a whiteboard.

Why NASA cannot simply rewrite everything in modern languages

This is the part where every confident person on the internet says, “Why not just port it?” Because aerospace is not a weekend hackathon.

First, validated code has enormous value. If a piece of mission software has been tested, trusted, and proven over years or decades, rewriting it introduces risk. Even if the new version is technically cleaner, it must still be verified, validated, and integrated with the rest of the system. In a mission environment, “probably equivalent” is not a comforting phrase.

Second, old systems often encode institutional knowledge that is nowhere else. NASA and JPL have both documented the challenge of software heritage and long-duration operations. Sometimes the issue is not just the code. It is the surrounding logic, the undocumented workaround, the odd naming convention, the reason one margin was conservative and another was not. In many long-lived systems, the code is only half the map. The other half is trapped in design memos, mission notes, or the memory of people who retired years ago.

Third, older software may be tightly coupled to older hardware, data formats, or operational procedures. A rewrite can ripple outward into tooling, training, testing, interfaces, and even mission rules. Suddenly, what looked like a modernization project becomes a years-long campaign with the budgetary charm of a small asteroid strike.

That is why NASA has often chosen a more measured strategy: preserve what still works, modernize selectively, wrap old capabilities with newer tools when possible, and keep people around who can still speak the original language. It is less glamorous than a total rewrite, but space engineering is not a glamor contest. It is a consequence contest.

What kind of programmer does NASA actually need?

Not just someone who can write FORTRAN on a whiteboard and say “behold.” NASA needs people who combine old-language fluency with systems thinking, patience, and a strong stomach for ambiguity.

The ideal engineer for this kind of work is part programmer, part historian, part detective, and part diplomat between generations of technology. They need to read old code without mocking it, because old code that still runs in deep space has already won several arguments. They need to understand modern software engineering well enough to modernize safely, but also respect why an older implementation existed in the first place.

That means knowing how memory limits shape design, how operations constraints influence architecture, how documentation gaps create risk, and how to make changes that are tiny in size but huge in consequence. It also means being comfortable with the fact that success may look boring from the outside. In aerospace, the best software update is often the one nobody notices because nothing exploded, drifted, reset, overheated, or started speaking in nonsense telemetry.

The bigger lesson: old code is not the enemy

There is a broader lesson here for every industry that worships novelty a little too hard. Old code is not automatically bad code. Sometimes it is just code that survived because it kept doing its job. In high-reliability environments, longevity itself is evidence. Not proof of perfection, obviously, but evidence that the software sits inside a web of trust built through tests, operations, maintenance, and hard-earned experience.

NASA’s need for programmers who understand older languages should remind us that progress in technology is not always about replacement. Sometimes it is about translation. Sometimes it is about stewardship. And sometimes it is about realizing that the future depends on people who can read the past without rolling their eyes.

That is especially true in space, where missions can outlive hardware vendors, documentation standards, and the people who wrote the first lines of code. In that environment, the programmer who can bridge 1977 and 2026 is not old-fashioned. That programmer is essential.

Experiences from the world of long-lived space software

To understand why NASA needs this rare kind of programmer, it helps to think about the experience of maintaining a mission that was never supposed to become a multigenerational software relationship. The original team builds for a five-year mission. Then the spacecraft keeps going. Then it keeps going some more. Before long, the code has outlived office furniture, filing systems, and some of the assumptions that shaped the original design. The new engineer is not simply inheriting a codebase. They are inheriting a living machine with a memory, a history, and a stubborn refusal to retire on schedule.

That experience is mentally different from modern software work. In a typical app environment, if something goes wrong, you patch fast, deploy again, inspect logs, and repeat. In deep-space operations, every move is slower, weightier, and more final. A command can take many hours to arrive. A response can take many more hours to return. That delay changes the emotional texture of the work. You cannot poke the system every five minutes. You have to think ahead, simulate mentally, and send instructions with unusual discipline. It is less like coding at a startup and more like writing a careful letter to a machine that lives farther away than common sense.

There is also the strange human experience of reading old technical documents written by people solving problems with the tools and fears of another era. Margins were set differently. Memory was precious in a way modern developers barely feel in their bones. Naming conventions reflect hardware realities that no longer exist in mainstream computing. Sometimes the document tells you what decision was made, but not why. So the engineer becomes an interpreter of technical intent, piecing together logic from diagrams, notes, and old operational habits. It is part engineering and part respectful mind-reading.

And then there is the emotional experience of working on something iconic. Voyager is not just another machine. It is a spacecraft that has become a symbol of endurance, exploration, and human ingenuity. That can inspire people, but it can also add pressure. Every change feels larger because the mission means something to science, to history, and to the public imagination. Nobody wants to be the person remembered for introducing a bad fix to one of humanity’s greatest engineering artifacts. So the work rewards humility. The engineer has to believe in their analysis, but never become arrogant about it.

At the same time, there is a quiet thrill in solving problems under those constraints. Few programming experiences can match the satisfaction of understanding a legacy system well enough to coax another useful year, another safe update, or another clean packet of science data out of a spacecraft built when cassette tapes were normal. That is the part outsiders often miss. Legacy-language work at NASA is not dusty maintenance for its own sake. It is active exploration support. It is the craft of keeping extraordinary machines understandable long after the world that built them has changed.

So when NASA needs a programmer fluent in 60-year-old languages, what it really needs is someone who can operate across time: someone who respects the engineering logic of the past, works carefully in the present, and helps preserve discoveries for the future. That may not sound flashy in a recruiting slogan. But in spaceflight, it is close to heroic.

Conclusion

NASA needs programmers who understand 60-year-old languages for the simplest reason in the universe: some of its most important systems are older than the internet as we know it, and they still matter. Voyager, deep-space navigation software, Shuttle-era language history, and current Fortran tooling all point to the same conclusion. Old languages survive at NASA not because the agency is stuck in the past, but because certain missions, models, and validated systems are too valuable to discard carelessly.

In the end, the job is not about worshipping old code or rejecting new tools. It is about knowing when heritage is a liability, when it is an asset, and when the future depends on someone who can speak both languages at once: the language of modern engineering, and the language that helped get humanity to the stars in the first place.