El software que llevó a tres personas a la Luna se entregó con dos firmas.
Margaret Hamilton firmó el envío el 28 de marzo de 1969 y Daniel J. Lickly lo aprobó ese mismo día.
En el fichero CONTRACT_AND_APPROVALS.agc del programa Comanche055, que es el software del módulo de mando del Apollo 11, hay un bloque de firmas que parece sacado de un expediente administrativo cualquiera.
# SUBMITTED: MARGARET H. HAMILTON DATE: 28 MAR 69 # M.H.HAMILTON, COLOSSUS PROGRAMMING LEADER # APOLLO GUIDANCE AND NAVIGATION # # APPROVED: DANIEL J. LICKLY DATE: 28 MAR 69 # D.J.LICKLY, DIRECTOR, MISSION PROGRAM DEVELOPMENT
Margaret Hamilton murió el 30 de septiembre de 2026, a los noventa años, y el obituario del MIT se publicó el 7 de octubre. Había nacido en Paoli, Indiana, el 17 de agosto de 1936. En 1968 era subdirectora al cargo del equipo del módulo de mando y de servicio, dirigió después la División de Ingeniería de Software del laboratorio, y según el propio MIT llegó a coordinar los dos equipos de software de vuelo y a más de cuatrocientas personas. Su biografía ya la contamos en TecnoTimes al tratar el problema de código que acabó convertido en una disciplina, de modo que este artículo hace otra cosa, abrir los ficheros y leer lo que dicen.
Y lo primero que dicen obliga a una precisión que casi nunca se hace. Su firma está en Colossus, el software del módulo de mando. Los comentarios más conocidos, el que pide girar la antena, el que dice BURN BABY BURN y el que expresa la esperanza de que una solución sea provisional, aparecen en Luminary099, el software del módulo lunar. Algunos bloques pueden relacionarse documentalmente con programadores como Don Eyles y Peter Adler, pero eso no permite identificar al autor individual de cada comentario. Tampoco existe fundamento para atribuir esas líneas personalmente a Hamilton. Su contribución fue mucho más amplia, participó en el desarrollo técnico y dirigió equipos que construyeron un software cuya fiabilidad resultó decisiva para el programa Apolo.
Lo que se publica en GitHub no es exactamente el original.
Una almohadilla separa 1969 de 2009, y la convención es menos limpia de lo que se suele contar.
El repositorio que circula se describe como el código original del ordenador de guiado para el módulo de mando, Comanche055, y el lunar, Luminary099. No procede de una cinta recuperada sino de fotografías de una copia impresa que conserva el MIT Museum, digitalizada por Paul Fjeld y gestionada por Deborah Douglas desde el museo, y transcrita después por los voluntarios del proyecto Virtual AGC. Entre el papel de 1969 y el fichero de texto que uno abre hoy hay por tanto una cadena de manos.
Cada línea útil tiene cuatro partes, la etiqueta, la instrucción, el operando y el comentario tras una almohadilla. En el listado paginado aparecen además dos columnas previas con la dirección en memoria y la palabra octal que acabó tejida en la memoria de cuerda. Quien quiera moverse por el código conviene que busque por etiqueta y no por número de línea, porque la numeración del fichero de GitHub no se corresponde con la del listado impreso, y es el listado el que da las páginas que aquí se citan. Para leer ensamblador de esta familia sin perderse ayuda tener presente lo que TecnoTimes contó sobre cómo nació el lenguaje ensamblador y por qué se escribía así.
Sobre la autoría de los comentarios circula una regla que conviene matizar antes de usarla. Virtual AGC precede con una almohadilla los comentarios originales y con dos los añadidos posteriormente, así que la distinción básica funciona. Lo que no funciona es extenderla a tres almohadillas, porque esa marca no indica autoría sino directivas de maquetación del generador del listado, del tipo que fija el estilo, el fichero o el ancla. Hay además dos excepciones que rompen la regla en la primera pantalla, las líneas de número de página llevan dos almohadillas sin ser nota de nadie, y la cabecera del fichero también. El propio proyecto advierte que el método no está formalizado y que la anotación sigue en sus primeros pasos, de modo que no cubre por igual todos los listados.
Una segunda clave cambia la lectura por completo. Cuando aparece TC INTPRET, el código deja de ser ensamblador puro y pasa a un lenguaje interpretado de más alto nivel, con operaciones vectoriales y de doble precisión, hasta que una instrucción de salida devuelve el control. Por eso hay bloques donde conviven dos operaciones en una línea. La rutina de inicialización de banderas del módulo lunar entra por esa puerta y su autor la etiquetó FLAGORGY, con el comentario DIONYSIAN FLAG WAVING, en la página 785.
Dato TecnoTimes. La versión que circula del software lunar es Luminary099. Existe también Luminary098, que es otra revisión del mismo programa y no la que descendió sobre el Mar de la Tranquilidad. Es un error de cita frecuente, porque los dos listados están publicados uno al lado del otro y comparten casi todos los ficheros.
El ordenador no se fiaba de lo que el astronauta decía haber hecho.
La rutina P63SPOT3 pregunta al sensor, nunca al tripulante, y vuelve a preguntar lo mismo.
En el fichero THE_LUNAR_LANDING.agc, página 789, hay diez líneas que se entienden sin saber ensamblador y que resumen una filosofía de diseño completa.
P63SPOT3 CA BIT6 # IS THE LR ANTENNA IN POSITION 1 YET
EXTEND
RAND CHAN33
EXTEND
BZF P63SPOT4 # BRANCH IF ANTENNA ALREADY IN POSITION 1
CAF CODE500 # ASTRONAUT: PLEASE CRANK THE
TC BANKCALL # SILLY THING AROUND
CADR GOPERF1
TCF GOTOPOOH # TERMINATE
TCF P63SPOT3 # PROCEED SEE IF HE'S LYINGEl ordenador lee un bit del canal 33 para saber si la antena del radar de aterrizaje está ya en la posición 1. Si lo está, continúa. Si no, muestra el código 500 y pide al tripulante que gire el chisme. A partir de ahí hay dos salidas, terminar el programa o pulsar PROCEED, y la segunda no da nada por bueno. Devuelve el control a la misma etiqueta, con el comentario SEE IF HE’S LYING, para volver a interrogar al sensor.
La decisión de ingeniería que hay detrás es que la palabra del operador no constituye evidencia. Pulsar PROCEED sin haber girado la antena devuelve al astronauta a la misma pregunta tantas veces como insista. Es la misma distinción que TecnoTimes examinó al preguntarse qué queda verificado cuando una prueba formal compila, porque en los dos casos el sistema certifica una comprobación concreta y no la afirmación de quien la reclama. Cuando la antena por fin responde, la línea siguiente es un salto a la rutina maestra de encendido con el comentario OFF TO SEE THE WIZARD, en la misma página.
El mismo fichero cierra el descenso con otro comentario dirigido al tripulante. Tras el aterrizaje, en la página 791, la rutina de pantalla lleva anotado ASTRONAUT, NOW LOOK WHERE YOU ENDED UP.
Once registros en el comentario, doce en la constante.
Los comentarios más citados del Apolo no son chistes, son miedo profesional puesto por escrito.
En EXECUTIVE.agc, el planificador de tareas del ordenador, hay un desajuste que se ve a simple vista en cuanto se ponen dos líneas juntas. La constante que fija cuántos bloques de registros hay disponibles para arrancar un trabajo nuevo se carga con un comentario que afirma que son siete conjuntos de once registros cada uno. La constante que define el salto entre un conjunto y el siguiente dice doce.
CAF NO.CORES # SEVEN SETS OF ELEVEN REGISTERS EACH. ... NO.CORES DEC 7 COREINC DEC 12 # 12 REGISTERS PER CORE SET.
El código utiliza una separación de doce registros entre conjuntos, mientras que el comentario habla de once. La discrepancia es real, aunque no conocemos su origen. Podría proceder de una modificación anterior o responder a una distinción entre los registros reservados y los utilizados, pero ninguna de esas explicaciones queda demostrada por las líneas examinadas. Lo verificable es que el valor de COREINC determina el desplazamiento entre conjuntos. Es un ejemplo de por qué los comentarios deben contrastarse con las instrucciones y las constantes que realmente utiliza el programa.
Hay más anotaciones del mismo tipo y conviene no leerlas como gracias. En LUNAR_LANDING_GUIDANCE_EQUATIONS.agc, página 801, dentro del bloque VRTSTART que inicia el descenso vertical, el par de líneas que llama a la rutina de anulación de velocidades de giro lleva repetido el comentario TEMPORARY, I HOPE HOPE HOPE. La expresión revela que su autor consideraba provisional aquella solución, aunque el comentario no permite establecer cuándo se introdujo ni por qué permaneció en la versión utilizada durante la misión. En la página 787, en el fichero del aterrizaje, un comentario de dos líneas dice HOPEFULLY ?GUIDSUB DID NOT CLOBBER RATT1 AND VATT1, con el interrogante incluido tal como aparece en el listado. Y en la página 810 una constante de ganancia de frenado está anotada simplemente como NUMERO MYSTERIOSO.
La rutina que vigila los modos automáticos durante el descenso merece una aclaración práctica. El comentario la llama GUILDENSTERN y describe su filosofía, pero la etiqueta por la que hay que buscarla en el fichero es GUILDEN, en la página 800. Lo que hace es más fino de lo que suele resumirse. En cada aparición o desaparición del acelerador manual selecciona P67 o P66 respectivamente, y en cada aparición del discreto de mantenimiento de actitud selecciona P66, salvo que el programa en curso ya sea P67, caso en el que no cambia nada.
La alarma 1202 y lo que de verdad hizo el ordenador.
BAILOUT1 no enciende ninguna luz y el rearranque que salvó el aterrizaje ocurre en otro fichero.
El mecanismo que genera las alarmas aparece en EXECUTIVE.agc, pero su causa durante el aterrizaje del Apollo 11 hay que buscarla también en el hardware. El radar de encuentro provocaba interrupciones inesperadas que consumían parte de la capacidad de procesamiento del ordenador. El planificador necesitaba mantener disponibles sus recursos para ejecutar nuevos trabajos. Cada core set era un conjunto de registros destinado a conservar el estado de un trabajo, y cuando los siete estaban ocupados se producía la alarma octal 1202, acompañada por el comentario NO CORE SETS AVAILABLE. La alarma 1201 indicaba otro agotamiento, el de las áreas VAC utilizadas por los trabajos interpretativos. El código examina cinco áreas, identificadas como VAC1USE hasta VAC5USE. Las alarmas no describían por sí mismas un fallo irreversible, sino condiciones de saturación que activaban los mecanismos de recuperación del sistema.
Lo que ocurre después se cuenta casi siempre mal, y el código no lo sostiene. La rutina BAILOUT1, en ALARM_AND_ABORT.agc, no escribe el código en ningún registro ni enciende nada. Pasa el control a un punto común que acaba en la rutina de comprobación de fallos, y lo que esa rutina hace con el registro FAILREG es consultarlo para saber si ya había una alarma previa. La luz del panel se enciende más adelante, en la rutina PROGLARM, a la que se llega con un salto anotado TURN ALARM LIGHT ON FOR FIRST ALARM, y que la activa manipulando la tabla de pantalla con una máscara octal.
La otra vía es la del rearranque, y tampoco está donde se dice. La rutina WHIMPER termina en un salto a una rutina llamada ENEMA, que no está definida en el fichero de alarmas sino en FRESH_START_AND_RESTART.agc, junto a otras dos de limpieza con nombres igual de elocuentes. Allí, el comentario que describe la entrada al rearranque dice que se vuelven a lanzar los programas que estuvieran corriendo en ese momento, y la vía del verbo 37 explica que toda la actividad en curso salvo el encuentro y el seguimiento se interrumpe borrando los grupos de rearranque.
La recuperación fue posible gracias a una arquitectura que combinaba planificación por prioridades y rearranques controlados. Cuando aparecieron las alarmas, el ordenador pudo restablecer los programas necesarios para continuar el descenso, sin recuperar todos los trabajos asociados al radar de encuentro que habían contribuido a la saturación. La documentación técnica conservada por la NASA confirma que esta capacidad había sido probada extensamente antes de la misión. En Houston, los controladores evaluaron las alarmas y autorizaron la continuación del aterrizaje. El éxito no dependió de una única instrucción ni de una decisión improvisada, sino de la interacción entre la arquitectura del software, las pruebas previas y el criterio de quienes supervisaban el descenso. Esa combinación constituye una de las aportaciones más importantes de la ingeniería desarrollada por el equipo de Hamilton.
En ese mismo fichero de rearranque hay una línea que resume la cultura de aquel equipo mejor que cualquier anécdota. Junto a las rutinas más peligrosas del programa, alguien escribió DO NOT USE GOPROG2 OR ENEMA WITHOUT CONSULTING POOH PEOPLE, donde los POOH PEOPLE son los responsables del programa P00, al que se vuelve por una etiqueta llamada GOTOPOOH.
Una sola rutina de encendido para cinco programas distintos.
Posición editorial de TecnoTimes sobre lo que el código demuestra y lo que la leyenda le añade.
El fichero con el nombre más famoso del repositorio ocupa las páginas 731 a 751 y es la rutina maestra de encendido del motor. Su cabecera declara que fue concebida y ejecutada, y añade entre paréntesis un NOTA BENE antes de decir que la mantienen Adler y Eyles. Le siguen dos lemas que conviene no confundir, HONI SOIT QUI MAL Y PENSE, que es el de la Orden de la Jarretera y no está en latín, y NOLI SE TANGERE, un latín defectuoso que apunta a la idea de no tocar esto y que está colocado justo encima de las tablas, a modo de advertencia para otros programadores.
El nombre tiene una explicación de primera mano dentro del propio fichero, en forma de anotación añadida por Virtual AGC. Don Eyles la dio en el encuentro de desarrolladores del ordenador de guiado celebrado por el cuarenta aniversario del primer paseo lunar, en 2009, y la hizo remontar a 1965 y a los disturbios de Los Ángeles, con el locutor Magnificent Montague gritando «Burn, baby! BURN!» al pinchar los discos más calientes.
Lo interesante no es el nombre sino el diseño. La cabecera declara que una misma rutina maestra de encendido puede utilizarse desde cinco programas del módulo lunar, el P12, el P40, el P42, el P61 y el P63. Parte de las diferencias necesarias para atender esos programas se organiza mediante tablas y direcciones de memoria, en lugar de duplicar íntegramente la lógica de encendido. El registro borrable WHICH interviene en la selección de los datos correspondientes y la rutina utiliza instrucciones de indexación para acceder a ellos. Es un ejemplo temprano de reutilización de software y de organización del comportamiento mediante datos, desarrollado bajo importantes restricciones de memoria. Eso no significa que todas las diferencias funcionales entre los cinco programas estén contenidas exclusivamente en tablas. En el mismo fichero conviven con ese diseño los comentarios EXTIRPATE JUNK LEFT IN DVTOTAL y ASSASSINATE CLOKTASK, y una rutina que abre con HELLO THERE y se despide con GOODBYE, COME AGAIN SOON.
La posición de TecnoTimes, que es juicio editorial y no un hecho verificado, tiene tres partes. La primera es que este código se divulga mal cuando se reduce a una colección de chistes, porque algunas de sus anotaciones más reveladoras expresan incertidumbre técnica y dejan constancia de soluciones cuya permanencia preocupaba a sus autores. La segunda es que atribuir esas líneas personalmente a Margaret Hamilton, sin documentación que lo respalde, confunde el homenaje con la exactitud histórica. Su contribución fue mucho más amplia que la escritura de instrucciones concretas. Participó en el desarrollo técnico del software Apolo, dirigió equipos de programación y contribuyó a establecer métodos de ingeniería orientados a la fiabilidad de sistemas donde un fallo podía comprometer una misión. La tercera es que la lección aprovechable sigue intacta. Aquel software incorporaba mecanismos para afrontar errores de operación, saturaciones del ordenador y situaciones imprevistas. El éxito del aterrizaje fue también el resultado de una ingeniería que había previsto la posibilidad de que las cosas salieran mal.
Queda una incertidumbre que conviene no tapar. Cincuenta y siete años después, la comparación con los programas lunares actuales se ha hecho muchas veces y TecnoTimes la abordó al revisar qué pasa cuando se actualiza un programa espacial cinco décadas más tarde. Lo que resulta especialmente revelador es la distancia entre los medios disponibles entonces y las posibilidades actuales de conservación y estudio del software. El bloque de firmas de Hamilton y Lickly documenta una entrega formal, mientras que los ficheros que hoy podemos consultar proceden de la transcripción de listados impresos conservados en el MIT Museum. Su digitalización permitió recuperar instrucciones y comentarios escritos hace más de medio siglo. No conocemos por esa fuente todos los procedimientos originales de respaldo, pero sí la cadena documental que ha hecho posible que aquel código siga siendo objeto de análisis.
Referencias.
Fuentes y documentación utilizada.
Luminary099. FRESH_START_AND_RESTART.agc, rutinas ENEMA, V37KLEAN y MR.KLEAN y lógica de rearranque.
🧠 DEBATE TECNOTIMES | El código del Apolo y su leyenda, 2026
¿Corregir una atribución falsa en pleno homenaje resta a quien se homenajea o es la única forma de respetarlo?
La popularidad del código del Apollo 11 ha favorecido que algunos de sus comentarios más llamativos se atribuyan personalmente a Margaret Hamilton. Sin embargo, su firma aparece en el software del módulo de mando, mientras que muchos de esos comentarios pertenecen al programa del módulo lunar. Algunos bloques pueden relacionarse con desarrolladores como Don Eyles y Peter Adler, pero no existe fundamento documental para atribuir individualmente todas esas líneas a Hamilton. La cuestión no es restarle protagonismo, sino reconocer con precisión cuál fue su verdadera contribución.
Corregir una atribución histórica poco después del fallecimiento de su protagonista puede parecer una forma de debilitar un homenaje. Pero mantenerla tampoco hace justicia a su trayectoria. Margaret Hamilton participó en el desarrollo técnico del software Apolo, dirigió equipos de programación y contribuyó a establecer métodos de ingeniería orientados a la fiabilidad. Su legado no necesita comentarios atribuidos sin pruebas. La pregunta es si preferimos homenajear a una figura histórica por lo que realmente hizo o por una versión simplificada de su historia.
- 🧩 ¿Tiene sentido exigir precisión en la atribución cuando la persona homenajeada acaba de morir, o ese es justamente el momento en que la precisión importa más?
- 🔍 Cuando un comentario histórico habla de once registros y el código establece una separación de doce, ¿debemos conservar la discrepancia original y explicarla o corregirla para facilitar su interpretación?
- ⚖️ En una rutina del Apollo 11, pulsar PROCEED no bastaba para confirmar que una antena estuviera colocada correctamente. El ordenador volvía a consultar el sensor. ¿Deberían nuestros sistemas actuales exigir comprobaciones semejantes antes de aceptar una acción como realizada?
- 🚨 ¿Qué se pierde cuando un repositorio histórico circula por sus chistes y no por sus decisiones de diseño?
