The Engineer Who Planned for Everything Going Wrong

When I was a kid, about 5 years old, I dreamed about being an Astronaut. I was obsessed with Space. As I grew older, I started reading more and more about scientific topics: physics, biology, astronomy, chemistry. My curiosity grew with my size. My dad taught at one of the main Universities in Caracas, he used to take me from time to time to the labs to watch the experiments and, sometimes, make some myself guided by another Professor. I had a microscope at home and, eventually, also a telescope. My curiosity for Space never left.

As a teenager, I got into computers and the dream of going to space faded, but not the love for Space. My curiosity let me to read about how computers made space missions possible, and that's how I found out about Margaret Hamilton.

On September 30, she died in Cambridge, Massachusetts, at the age of 90. You probably have seen the photo of a young woman standing next to a stack of printed source code as tall as she is over the internet. That stack was the Apollo flight software, and her team wrote it.

A lot has been said about her contributions to NASA and sending the first man to the Moon and back. But I'd like to talk about something else. The way she thought about failure. Because, to me, what made her great isn’t that her code worked when everything went right, that's standard and almost a given if you're a competent engineer. It’s that it kept working even when things went wrong.

Three minutes before moon landing

On July 20, 1969, as the Eagle lunar module descended toward the surface of the moon, the guidance computer started throwing alarms: error code 1202, then 1201. The reason was that a radar switch had been left in the wrong position, flooding the computer with work it didn’t need to do. It was overloaded.

Any system would have crashed, I've seen many applications just hang and die because they are out of memory. Hamilton’s didn’t. The software was designed to know what mattered most and act on priorities. Under overload, it restarted, shed low-priority tasks, and kept the core critical ones running: guidance, navigation, landing. The alarms were less and less frequent, Mission Control called “GO”. Armstrong and Aldrin landed safely in the Sea of Tranquility.

That’s not luck. That’s design.

Her daughter found a bug

One of the stories I love most is that Hamilton sometimes brought her young daughter, Lauren, to the lab. One day Lauren was playing with the simulator and triggered a pre-launch program, P01, in the middle of a simulated flight. This caused the system to crash.

Hamilton wanted to add protection against it. She was told it wasn’t necessary; astronauts were trained, they would never do that. So she added a note to the documentation instead.

Then, on Apollo 8, Jim Lovell did exactly that.

The lesson every engineer eventually learns the hard way: “the user would never do that” is not a design strategy. Users will, trained users, astronauts, your future self at 2 a.m without enough coffee.

She gave our job a name

Hamilton started calling what she did “software engineering” at a time when software wasn’t taken seriously as a discipline, and people laughed. She insisted on it because she wanted the work to get the same rigor and respect as hardware. She won that argument. Every one of us with that word on our LinkedIn is living in the world she argued for.

What I take from her into API design

I write a lot about APIs here, and I keep coming back to the same ideas she was practicing sixty years ago:

• Assume misuse. Validate everything. Never let a client put your system in a state you didn’t plan for, no matter how “obvious” it is that they won’t.
• Prioritize under pressure. Rate limits, load shedding, and degraded modes aren’t nice-to-haves. Decide in advance what your system protects when it can’t do everything.
• Fail loudly and recover. The 1202 and 1201 alarms were not silent failures. They told people exactly what was happening, and the system recovered on its own. Good error responses do the same.
• Errors are part of the design, not an afterthought. Her team spent as much thought on what happens when things break as on the happy path.

Thank you, Margaret

She received the Presidential Medal of Freedom in 2016, and later in life became a symbol for women in tech, which she was. But she was also, simply, one of the best engineers who ever lived.

The next time you write a guard clause for a case that “can’t happen,” think of her. That’s her legacy, running in production everywhere.

If you like what you've read so far or resonate with my opinions, subscribe to my mailing list, it's free and you'll get all my writings twice a month on your inbox.