El 30 de septiembre de 2026 murió en Cambridge, Massachusetts, Margaret Hamilton. Tenía 90 años y la mayoría de la gente no sabe su nombre, pero todos los que hacemos software somos herederos de su pega. La noticia reventó en Hacker News con casi dos mil puntos, y me parece que merece más que un tuit respetuoso: merece que expliquemos por qué lo que hizo en los 60 sigue siendo el estándar que casi nadie aplica en 2026.
Quién era esta weona (en el buen sentido)
Hamilton entró al Laboratorio de Instrumentación del MIT en 1965, contratada para programar la computadora de vuelo del programa Apollo. Era la primera programadora del proyecto y dirigió al equipo que escribió el software de navegación a bordo de las misiones tripuladas. En su peak, más de 400 personas trabajaban bajo su coordinación. A ella se le atribuye popularizar el término software engineering: antes de eso, escribir código se veía más como artesanía que como ingeniería.
Su obsesión era una sola: ¿qué pasa cuando el sistema falla? Y no falla por malicia, sino por puro error humano.
La anécdota que lo explica todo
En 1968, su hija Lauren, jugando con el simulador de alunizaje en la oficina, apretó un botón que lanzó un proceso que colapsó todo. Hamilton entendió que si una niña lo hacía por accidente, un astronauta cansado, con la adrenalina al máximum, también podía. Empezó a exigir código de recuperación ante errores y prioridades de ejecución cuando los recursos se agotaban. Los jefes de la NASA la miraban como si estuviera loca: «los astronautas jamás harían eso».
Meses después, en Apollo 8, el astronauta Jim Lovell apretó exactamente ese botón equivocado y borró los datos de navegación. El software que Hamilton había defendido se reinició, recuperó la prioridad del proceso crítico y la misión siguió. No fue suerte: fue diseño.
Por qué me da rabia esta historia en 2026
Porque trabajo con sistemas donde un fallo no es un pantallazo azul: es una máquina de cientos de toneladas haciendo algo peligroso, y mi pega diaria es exactamente la misma pregunta de Hamilton: ¿qué pasa cuando el operador hace lo imposible?
Pero miro alrededor y veo lo contrario. Hoy la IA genera código a caleta, los agentes corren en cron sin supervisión, y el error handling se escribió con except: pass porque «funcionó en pruebas». Nadie piensa en prioridades cuando la CPU se congestiona, en idempotencia cuando un retry dispara dos veces, en qué le muestra el sistema al humano cuando el humano es la parte frágil. Hamilton lo resolvió con 36KB de RAM y sin Stack Overflow.
Takeaway accionable
Antes de cerrar tu próximo ticket, hazte las tres preguntas de Hamilton:
- ¿Qué pasa si el usuario hace el movimiento imposible? Si la respuesta es «colapsa», no está listo.
- ¿Cómo se recupera el sistema? Reiniciar limpio y priorizar lo crítico es más valioso que prevenir todo.
- ¿Qué proceso gana cuando los recursos se acaban? Esa jerarquía debe estar en el diseño, no improvisada a las 3 AM.
Ella demostró en 1969 que el error humano no es una culpa del usuario: es un requisito del diseño. Casi 60 años después, seguimos olvidándolo con cada deploy. Descansa, Margaret. El resto del software te debe harto más de lo que admite.
Fuente de inspiración: Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90
