Outlook in Orbit

There was a time when writing software for space meant fear. Not the poetic kind, the engineering kind. 

The kind that led NASA Jet Propulsion Laboratory to adopt rules so strict they bordered on asceticism: no recursion, no dynamic memory, no ambiguity. Code was something you constrained, not something you let grow wild. The machine was small, the margins were thin, and the consequences were absolute.

This was the spirit behind the “Power of Ten” rules, software designed less like a product and more like a contract with physics. And now, somewhere in the cultural imagination (and possibly in a tablet floating gently in microgravity), sits Microsoft Outlook. Of course, Outlook is not flying the spacecraft. It is not computing trajectories, firing thrusters, or keeping astronauts alive. It is, we are assured, safely sandboxed. Just another tool in the digital ecosystem that surrounds modern missions. But that’s not really the point.

The point is that Outlook represents something very different from the old NASA ethos. It is not minimal, or predictable, or constrained. It is the product of decades of feature accretion, enterprise requirements, backward compatibility, and the quiet chaos of modern software development. It is, in other words, the opposite of everything that once defined mission-critical code.

This is not a story about Outlook, exactly. It is a story about what happens when two worlds collide: the world of high-assurance systems, where failure is catastrophic, versus the world of general-purpose software, where failure is routine and survivable

For most of tech history, these worlds were kept carefully apart. You didn’t run office software in a nuclear reactor control system. You didn’t patch a spacecraft mid-flight. You built small, understandable systems, and you trusted them because you could understand them. But modern systems don’t work like that anymore.

They are layered. Interconnected. Dependent on vast stacks of software, much of it written far away from the domain in which it’s ultimately used. Even when critical systems remain isolated, they exist within a broader ecosystem that is anything but simple. And so, inevitably, the aesthetic changes.

Apollo was a triumph of constraints. Artemis is a negotiation with complexity.

Apollo’s software fit in tens of kilobytes. Artemis exists in a world of gigabytes, cloud services, and global supply chains. The challenge is no longer just writing correct code as it is managing the interfaces between systems that were never designed to coexist. Microsft Outlook, in this context, becomes a kind of symbol. Not because it’s dangerous, but exactly because it’s familiar. It reminds us that even at the edge of human exploration, we are still dragging along the full weight of our technological civilization: from conveniences to its quiet absurdities.

There’s something almost poetic about it. A spacecraft slips the bonds of Earth, guided by some of the most rigorously engineered systems ever built… while, somewhere nearby, a calendar event is trying - and failing - to synchronize.

“Meeting: Lunar Surface Operations Review”
Status: Tentative
Location: Moon
Attachments: (2)
Error: Connection interrupted

The engineers, of course, know better. They know where the boundaries are. They know what is isolated, what is verified, what is safe. But the rest of us can’t help noticing the contrast. From Power of Ten to “Reply All,” human spaceflight has not properly evolved, having accumulated instead. And maybe that’s the real story: Not that we’ve abandoned rigor, but that we now build it on top of a world that no longer believes in simplicity.