Artemis II Is Airborne: What a 54-Year Gap Teaches About Knowledge Decay in Engineering

What happened

NASA's Artemis II mission launched from Kennedy Space Center, sending four astronauts on a roughly 10-day flight around the Moon and back. Commander Reid Wiseman, pilot Victor Glover, mission specialist Christina Koch, and Canadian Space Agency astronaut Jeremy Hansen are the first humans to leave low Earth orbit since Gene Cernan climbed back into Apollo 17's command module in December 1972. The gap between the last Apollo crew and this one is 54 years — longer than the entire history of human spaceflight that preceded it.

This is not a landing mission. Artemis II is a lunar flyby: the crew will loop behind the far side of the Moon and return to Earth, validating the Orion spacecraft's life support, navigation, communication systems, and — critically — its heat shield during a 25,000 mph atmospheric reentry. The unmanned Artemis I completed this trajectory in late 2022, but nobody was aboard to verify that the cabin stayed livable.

One technical detail worth flagging: Artemis II is using laser-based optical communication to live-stream 4K video from lunar distance at 260 Mbps. For context, Apollo beamed back fuzzy TV at roughly 500 kbps. That's a 500,000x bandwidth improvement — and it's a prerequisite for any serious deep-space operations where ground teams need real-time situational awareness.

And in a detail that HN found irresistible: one of Artemis's onboard computers was discovered running two instances of Microsoft Outlook, and engineers reportedly couldn't explain why. If that doesn't capture the state of modern systems engineering, nothing does.

The institutional knowledge problem

The most underappreciated fact about Artemis is that NASA could not simply dust off Apollo hardware and fly again. Almost nothing from Apollo survived in a usable form — not the manufacturing tooling, not the supply chains, not the engineering workforce, and in many cases not even the documentation. The F-1 engines that powered the Saturn V were built by Rocketdyne using hand-welded techniques that weren't formally documented. When NASA engineers examined recovered F-1 engines in the 2010s to study their injector plate design, they had to reverse-engineer components that were originally built by craftspeople who had long since retired or died.

The Artemis program has cost over $90 billion to date. A significant fraction of that is the cost of relearning things NASA once knew. Not inventing — *relearning*.

This is not a NASA-specific failure. It's a universal pattern in any organization that lets critical knowledge exist only in people's heads.

The same decay in software

Developers encounter knowledge decay constantly, usually at lower stakes and higher frequency.

The COBOL problem. An estimated 220 billion lines of COBOL are still running in production, processing roughly 95% of ATM transactions and 80% of in-person financial trades. The average COBOL programmer is in their 60s. During the 2020 unemployment surge, multiple US states discovered that their benefits systems ran on COBOL mainframes that no current employee understood well enough to modify safely. New Jersey's governor went on TV asking for volunteer COBOL programmers. The business logic encoded in those systems wasn't documented anywhere except the code itself — and the people who wrote it were gone. This is F-1 engine reverse-engineering, just with fewer explosions.

The "abandoned internal tool" trap. Every company of sufficient age has at least one internal system that nobody owns, nobody fully understands, and everybody depends on. It started as a side project. The author left. It works, so nobody touches it. Then a dependency breaks, or a security audit flags it, or it needs to integrate with a new system, and suddenly you're doing archaeological excavation on a Flask app with no tests, no comments, and database migrations that reference Jira tickets from a decommissioned Jira instance.

The bus factor, quantified. A 2022 study of 1,932 open-source npm packages found that 28% had a single maintainer responsible for over 90% of commits. When that person steps away, knowledge doesn't degrade gradually — it cliff-drops. The code is still there, but the *reasoning* behind the code is gone. Why is there a 200ms sleep in the retry loop? Why does the parser special-case timestamps from 2017? Was that a bug workaround or a business requirement? Dead code tells you *what*. Only living engineers tell you *why*.

What actually prevents knowledge decay

Artemis is a cautionary tale, but it's more useful as a diagnostic. The organizations that handle knowledge continuity well tend to share specific practices:

1. Decision records over documentation. Traditional docs describe the system as it is. They rot the moment the system changes. Architecture Decision Records (ADRs) capture *why* a choice was made, what alternatives were rejected, and what constraints existed at the time. ADRs age better because the reasoning behind a decision remains relevant even after the implementation changes. The Apollo equivalent would have been: "We hand-weld the injector plate because the tolerances exceed what our automated tooling can achieve" — a sentence that would have saved NASA years of reverse-engineering.

2. Rotation, not silos. The military rotates personnel through roles specifically to prevent single-person knowledge dependencies. In software, regular rotation of on-call duties, code ownership, and feature areas forces knowledge to distribute. It's slower in the short term. It's dramatically cheaper in the long term. NASA's 54-year gap is the extreme case: an entire *generation* rotated out simultaneously.

3. Tests as executable documentation. A well-written test suite is the one form of documentation that *must* stay current, because it fails if it doesn't. Tests can't capture every design decision, but they encode behavioral expectations in a form that outlives any individual contributor. The COBOL systems that cause the most pain are invariably the ones with no test coverage — you can't safely change what you can't verify.

4. Controlled deprecation over abandonment. The difference between Apollo and, say, the Linux kernel is that the kernel has never gone cold. Continuous development — even at reduced intensity — maintains the knowledge gradient. When you decommission a system, the knowledge leaves with it unless you actively migrate both the functionality *and* the context to whatever replaces it.

The real lesson

Artemis II is a $90 billion proof that knowledge is not an artifact — it's a process. You can't freeze-dry expertise into documents and reconstitute it decades later. The documentation helps, but what actually preserves institutional knowledge is continuous engagement: people working on the system, arguing about it, teaching newcomers, and — critically — making mistakes in a context where there are still people around who remember why things are the way they are.

The four astronauts currently looping around the Moon are riding hardware that took two decades and $90 billion to rebuild because nobody maintained the knowledge pipeline. Every team that lets a senior engineer leave without a transition plan, every company that treats documentation as a checkbox instead of a practice, every org that assumes the code speaks for itself — they're all running a miniature Artemis program. The only question is how long the gap gets before they have to pay the relearning tax.