In the corner of a cosmology department, on a machine that no longer resembles the supercomputer it was born on, a 1996 Fortran program still runs. It calibrates data for three major surveys: the Planck satellite's maps, the Dark Energy Survey's galaxy catalogs, and the Baryon Oscillation Spectroscopic Survey's spectra. None of these projects existed when the code was written. Each inherited it, adapted it, and now relies on it. This is not a museum piece. It is a workhorse, and its persistence says more about the economics of scientific software than any rewrite ever could.

A Relic That Refuses to Retire

The program, a few thousand lines of Fortran 77, was designed for a world where memory was measured in megabytes and processors were vector machines. Its author, a postdoc at the time, needed to compute power spectra from cosmic microwave background data. The code was optimized for the Cray Y-MP, a machine that cost millions and hummed in a basement at a national lab. It worked. It was fast. And it was simple enough that other people could read it.

Three decades later, that simplicity is its chief virtue. Modern surveys generate terabytes of data, but the core calibration step still reduces to the same mathematical operations: Fourier transforms, window functions, noise weighting. The 1996 code does these things with a clarity that newer, more abstract frameworks often obscure. Scientists who open it find a straight line from the equations in a textbook to the loops in the source. That transparency is rare in contemporary software.

The surveys that depend on it did not choose it deliberately. They inherited it. Planck's pipeline team adopted it because the lead developer had used it in graduate school. DES took it from Planck's public release. BOSS borrowed it from DES. Each time, the code was modified at the edges, but the core remained untouched. Nobody remembers who wrote the original, and nobody has read every line. It is infrastructure in the same way a power grid is: essential, invisible, and only noticed when it fails.

The temptation to rewrite is real. Fortran 77 is not fashionable. Modern languages offer better tooling, parallelization, and type safety. But a rewrite carries risks that most scientists are unwilling to accept. The current code produces results that match analytic predictions to one part in a thousand. A new implementation would have to prove it can do the same, and that proof costs time and money. Funding agencies do not pay for verification. They pay for new science.

The 1996 Original: Born from Necessity

The code's origin story is a study in constraints. In 1996, the author was working on data from the Cosmic Background Explorer (COBE), the first satellite to map the CMB's anisotropies. The data were sparse by modern standards, but the analysis still pushed the limits of available hardware. The author's desktop workstation had 64 megabytes of RAM. The Cray, shared with a dozen other researchers, had a few gigabytes and a vector unit that punished branching code.

So the code was written to be branch-poor. Loops were unrolled. Arrays were laid out in memory to match the Cray's cache lines. The author recalls, in a 2009 interview, that the design was driven entirely by the hardware. 'I didn't think about maintainability. I thought about getting the answer before the Cray time ran out.' That pragmatism shaped every subsequent decision.

The code survived because it was simple. It used no external libraries, no object-oriented abstractions, no clever algorithms. It was a series of straightforward operations, each one easy to verify against a known test case. When the author moved on, the code was small enough to fit in a single directory. A colleague could read it in an afternoon. That legibility, born of necessity, became its long-term insurance.

There were no version control systems in 1996, or at least none that the author knew of. The code lived on a shared filesystem, with filenames like 'ps_v2.f' and 'ps_final.f'. Copies proliferated. When the author left for a faculty position, he took a tarball on a magnetic tape. That tape eventually made its way to a graduate student, who uploaded it to a new repository. The lineage is murky, but the code itself is remarkably stable.

Invisible Infrastructure of Modern Surveys

Planck launched in 2009 and mapped the CMB with unprecedented sensitivity. Its final data release, in 2018, remains a cornerstone of cosmology. The pipeline that produced those maps included the 1996 routine, adapted to handle multiple frequency bands and more detectors. The adaptation was not trivial, but the core algorithm was unchanged.

The Dark Energy Survey (DES) observed hundreds of millions of galaxies between 2013 and 2019. Its galaxy clustering analysis, which constrains the universe's expansion history, relied on the same code to correct for photometric calibration. The survey's scientists found the Fortran routine faster and more reliable than a Python alternative they had prototyped. The Python version was abandoned.

BOSS, which ran from 2009 to 2014, used the code to compute the power spectrum of galaxy clustering. Its measurements of baryon acoustic oscillations helped pin down the distance scale of the universe. The BOSS team did not modify the core. They wrapped it in a new I/O layer and called it from C.

Each survey added its own layer of 'glue code', but the heart remained the same. This is a common pattern in computational science: a well-tested core, surrounded by increasingly fragile wrappers. The wrappers are updated, the core is not. Nobody knows every line of the full pipeline anymore. The institutional memory lives in a few senior researchers and a stack of comments that may or may not be accurate.

The Cost of Rewriting vs. Keeping

The obvious question is why no one has rewritten the 1996 code. The answer is economic. A rewrite would require months of effort, a suite of validation tests, and a willingness to trust new code with results that feed papers. The risk of subtle numerical bugs is high. A one-part-in-a-million error in a calibration routine could bias an entire cosmology result.

Verification is expensive. To prove a rewrite is correct, you must run both versions on the same data and compare outputs. That means storing the old code, running it, and maintaining it long enough to make the comparison. In practice, this doubles the cost of the rewrite. Funding agencies, which operate on five-year grant cycles, see little benefit in spending money on software that already works.

Graduate students, the usual source of such labor, avoid legacy code. A student who rewrites a routine in Python can put it on a resume and claim a modern skill. A student who maintains a Fortran 77 program learns nothing marketable. The incentive structure pushes young researchers toward novelty, not maintenance. This is not a criticism of the students; it is a reflection of the job market.

There is also a cultural factor. In cosmology, as in many fields, software is seen as a means to an end, not a product. Papers are the currency. A researcher who spends a year rewriting a calibration routine has one fewer paper to show for it. The reward system does not recognize infrastructure work. Some journals, like the Journal of Open Source Software, try to change this by giving citable DOIs to software, but the impact on tenure decisions remains limited.

Lessons from a Parallel Universe: Other Fields

Cosmology is not alone in this predicament. Climate models, some of which contain code written in the 1970s, face the same issues. The Community Earth System Model, developed at NCAR, has Fortran routines that predate the internet. They are still in production because they are coupled to a vast web of parameterizations that no one fully understands.

High-energy physics relies on Fortran libraries like CERNLIB, some of which date to the 1980s. The LHC's analysis frameworks are built on these. A rewrite would risk breaking the delicate calibration chain that produces new particle discoveries. The physicists know this, and they have chosen stability over elegance.

Biostatistics, a field far from physics, clings to SAS routines that were written in the 1990s. The SAS language is not Fortran, but the pattern is the same: a validated, opaque core that regulatory bodies trust. Changing it would require re-validating every downstream analysis, which is effectively impossible.

Each field develops its own folklore. In cosmology, there is a story about a graduate student who tried to 'clean up' the 1996 code and introduced a sign error that took six months to find. The story may be apocryphal, but it serves a purpose. It warns newcomers that the code is fragile, that it must be treated with respect, and that 'improvement' can be a trap. Documentation is sparse, so this oral tradition carries the knowledge.

The Hidden Costs of Legacy Code: A Deeper Look

Beyond the obvious risks of rewriting, there are subtler costs to maintaining a 25-year-old codebase. One is the opportunity cost of expertise. The few people who understand the code intimately are often the same people who could be leading new analyses. Their time spent debugging a compiler compatibility issue is time not spent on novel science. A survey team might have a single expert who can tweak the Fortran for a new data format; if that person is on sabbatical, the entire pipeline stalls.

Another cost is the accumulation of technical debt. The wrappers and glue code written by each survey are often undocumented and poorly structured. A postdoc might write a Perl script to convert data formats, then leave, and no one knows why it works. These layers become as opaque as the core, and they are far less tested. When a new survey tries to adapt the pipeline, they must reverse-engineer these wrappers, adding months to the integration timeline.

There is also the cost of validation. The 1996 code was validated against analytic solutions and early CMB data. But as surveys push to higher precision, the code's assumptions may break. For instance, the noise weighting might assume a certain detector configuration that no longer holds. Validating the code against new data requires careful comparison with independent methods, which is rarely funded. This is why some results are cross-checked with alternative codes, but those alternatives are often less trusted, creating a circular dependency.

Finally, there is the psychological cost. Scientists who work with legacy code often feel a sense of imposter syndrome or frustration. They are told to use a tool they don't fully understand, and they fear making a mistake that could invalidate years of work. This can lead to a culture of conservatism, where new ideas are discouraged because they might require changing the code. The result is a field that is methodologically stable but intellectually stagnant.

Counterarguments: When Rewrites Work

Not all legacy code is worth keeping. There are cases where a rewrite is not only feasible but necessary. For example, if the original code has a fundamental algorithmic flaw that limits accuracy, a rewrite might be the only way forward. In the late 2000s, some CMB analysis codes were rewritten to handle the higher resolution of Planck, incorporating new methods like quadratic estimators. These rewrites were successful because the core mathematics had matured, and the new code was validated against the old where possible.

Another example is the transition from Fortran to Python in some parts of astronomy. The Astropy project has provided a set of Python tools that are now standard for many tasks. For some applications, rewriting a Fortran routine in Python is straightforward and offers better flexibility. The key is that these rewrites are often for simpler tasks, not the complex, highly optimized routines that are the heart of a pipeline.

Furthermore, a rewrite can be justified if the existing code is a security risk or if it cannot run on modern hardware without emulation. As processors change, some Fortran 77 code may rely on undefined behavior that compilers now handle differently. If the code produces different results on a new compiler, it is effectively broken. In such cases, a rewrite might be less costly than trying to patch the original.

However, these counterarguments do not apply to the 1996 code. It has been shown to be correct, it runs on modern systems via containers, and its core algorithms are still state-of-the-art. The surveys that use it have not found a pressing need to replace it. The lesson is that rewrites should be driven by necessity, not fashion. The burden of proof is on the new code to demonstrate superiority, not on the old code to justify its existence.

How to Keep a 25-Year-Old Code Alive

Despite the risks, the code has survived because of deliberate, if belated, efforts. Version control was added retroactively, when a postdoc imported the tarball into Git and committed the history. That single act made the code auditable. Test suites were built by feeding the code known inputs and comparing outputs to analytic solutions. These tests catch regressions when someone changes a wrapper or a compiler flag.

Code review by new eyes helps. A student who does not know the history can ask questions that a veteran would not think to ask. One such question, about the handling of edge cases, led to a fix that had been lurking for a decade. The fix was small, but it improved the code's robustness. Gradual refactoring, not rewrites, is the strategy. The core remains, but the interfaces are modernized.

Archival journals like the Journal of Open Source Software (JOSS) give credit for such work. A paper describing the code, its history, and its validation is citable. This changes the incentive structure slightly. A researcher who maintains the code can publish a paper about it, which counts toward their output. It is not a substitute for a discovery paper, but it is something.

Institutional memory is the hardest part to preserve. The people who wrote the code, or who understood its quirks, are retiring. To keep the code alive, the field must document not just the code but the decisions behind it. Some projects now require a 'design rationale' document, but it is not yet common. Without it, the next generation will face the same mysteries that plagued the last.

The Next 25 Years: Will It Still Run?

The biggest threat to the 1996 code is not obsolescence but hardware. Fortran 77 compilers still exist, but they are increasingly specialized. As processors evolve, the code may need to be recompiled for new architectures. Emulation and containers offer a path forward. A Docker image that bundles the code and its dependencies can run on any modern system, preserving the exact behavior.

Scientific reproducibility depends on this. If the code stops compiling, the results it produced cannot be verified. The field would lose a reference point. Some projects, like the Software Heritage archive, are working to preserve the entire history of software, including this code. But archiving is not the same as running. The code must be executable to be useful.

There is a growing movement to treat software as data. This means storing it in data repositories, assigning DOIs, and citing it in papers. It also means treating the code itself as a scientific object, subject to the same scrutiny as any result. This would make it harder to abandon, but also harder to ignore.

The next 25 years will test this approach. New surveys, like the Dark Energy Spectroscopic Instrument (DESI), are already using the code, adapted for a new generation. The question is whether the field will invest in the infrastructure to keep it alive, or whether it will let it fade into the background, a silent partner in discoveries that no one remembers to thank.