Margaret Hamilton's colleagues laughed at 'software engineering'; Apollo needed its overload planning

Margaret Hamilton was trying to get software treated as engineering. Her colleagues thought the phrase was funny. Apparently the work that made the hardware useful needed a better name tag before it could join the meeting.

Hamilton described the exchange in her Computer History Museum interview. Programmers had been treated as “second-class citizens,” she recalled. She named their work alongside hardware engineering, and a respected hardware colleague eventually stood up for the idea. The story documents how she advocated for the discipline inside the Apollo effort; it doesn’t establish that nobody anywhere had used the words earlier.

MIT’s obituary reports that Hamilton died September 30, 2026, at 90. It credits her with leading the Apollo software engineering team and helping establish software engineering as a discipline. Remembering the team matters. A spacecraft carries considerably more collaboration than a single famous photograph can hold.

The physical machine was already respected as engineering. The decisions about what it should do when overloaded deserved the same treatment. A system can have correctly built parts and still face a moment when too many demands arrive together. Keeping everything equally important is an excellent way to make the important thing wait.

NASA’s Lunar Surface Journal account of the program alarms, written by Apollo participant Fred Martin, explains the specific protection. The priority-driven executive continued the highest-priority jobs when computer time became scarce. Lower-priority work could fall off the queue. Landing didn’t have to wait for every less urgent task to receive equal attention.

Martin’s account also describes the investigation into radar-related cycle stealing and the procedures that had instructed the crew to use the switch position involved. That is a more useful history than a story about an astronaut simply doing the wrong thing. The checklist and the connected system belonged in the investigation too.

A present-day operations team can borrow the question without pretending its next traffic spike is a lunar landing. When the machine runs short of time, what waits? Which result becomes stale? Does the system tell the person using it what happened, or leave them interpreting a spinning icon as a spiritual exercise?

Future software may automate more of its own construction, but deciding what it must preserve under failure remains a design choice somebody has to own. Hamilton’s record leaves a very practical demand: consider the unexpected while there is still time to change the system. The landing was a rather unforgiving place to postpone that discussion.

The Moon wasn’t taking bug reports.