Margaret Hamilton: el software también era ingeniería

Durante el descenso del Apolo 11, el ordenador de a bordo empezó a mostrar alarmas mientras la nave seguía acercándose a la superficie lunar. En ese momento importaba algo más que haber calculado correctamente una trayectoria: el sistema tenía que conservar la capacidad de guiarla mientras gestionaba un problema.

Este es un buen punto de entrada al trabajo de Margaret Hamilton. Su aportación combina desarrollo, dirección de equipos y una defensa sostenida del software como ingeniería: una actividad que debe hacerse responsable de lo que ocurre cuando las condiciones dejan de ser las previstas.

El legado de Hamilton ayuda a situar la fiabilidad dentro de la definición del producto, con recursos, pruebas y autoridad para decidir antes de que llegue el incidente. Apollo permite ver por qué esa reivindicación tenía consecuencias materiales.

Programar cuando la disciplina todavía se estaba construyendo

Hamilton llegó a la informática desde las matemáticas. Trabajó en el MIT en programas de predicción meteorológica con Edward Lorenz y, entre 1961 y 1963, participó en el sistema de defensa aérea SAGE. El Computer History Museum documenta esa trayectoria y sitúa en SAGE su interés creciente por la fiabilidad: un programa que fallaba tenía efectos visibles para los demás operadores del sistema.

El contexto importa. Había que aprender buena parte del oficio trabajando con las máquinas y con quienes las utilizaban. La relación entre un cálculo correcto, los recursos disponibles y el comportamiento del conjunto se descubría en problemas concretos. Hoy disponemos de décadas de métodos y herramientas; resulta fácil proyectar esa infraestructura profesional hacia una época en la que todavía se estaba formando.

En Apollo, Hamilton asumió responsabilidades de dirección del software de vuelo en el Instrumentation Laboratory del MIT. El trabajo abarcaba los programas de los módulos de mando y lunar. Su figura permite reconocer una parte de la exploración espacial menos visible que el vehículo: especificaciones, coordinación, revisión y decisiones sobre lo que debía hacer una máquina en condiciones extraordinarias.

La conocida fotografía de Hamilton junto a una pila de listados representa ese trabajo colectivo. La explicación histórica publicada por NASA identifica los programas como obra de ella y del equipo que dirigía. Convertir la imagen en «una mujer escribió sola todo el código que nos llevó a la Luna» borra precisamente una de sus aportaciones: organizar una labor de ingeniería que excedía a cualquier persona.

Apolo 11: una alarma podía ser compatible con continuar

Las alarmas 1201 y 1202 señalaron que el sistema ejecutivo no tenía disponibles determinados espacios de trabajo para atender nuevas tareas. El ordenador podía detectar esa situación y recuperar funciones esenciales. La existencia de una alarma, por tanto, necesitaba interpretarse junto con el comportamiento que seguía a ella.

La explicación técnica conservada en el Apollo Lunar Surface Journal distingue ambas condiciones: falta de áreas VAC en la 1201 y de conjuntos de trabajo, o core sets, en la 1202. Describe también una recuperación que reinicializaba el sistema y retomaba programas seleccionados cerca del punto en el que estaban. Eso preservaba funciones como el control del motor de descenso.

El margen era estrecho. Esa misma fuente documenta 36.864 palabras de memoria fija y 2.048 de memoria modificable para el ordenador del módulo lunar. Son unidades históricas de aquella arquitectura, no una comparación directa con los gigabytes actuales. Obligan a entender que asignar espacio y tiempo de cálculo formaba parte del diseño de la misión.

La recuperación había sido objeto de pruebas. Ahí está la diferencia que interesa trasladar al presente: conocer el funcionamiento normal de una aplicación y conocer qué conserva después de una interrupción son evidencias distintas.

También hubo una decisión humana. En su testimonio sobre el alunizaje, Fred Martin, responsable del MIT durante Apollo, relata la intervención de Jack Garman para recomendar que se continuara. El mismo relato explica la investigación posterior de la carga asociada al radar de encuentro y al consumo de ciclos del ordenador. Por eso conviene evitar la versión cómoda de «un astronauta se equivocó y el software lo arregló»: hardware, procedimientos, software y entrenamiento formaban parte del sistema.

Atribuir todo aquel resultado a Hamilton en solitario sería tan impreciso como excluirla. Su liderazgo pertenece a un esfuerzo con múltiples autores, especialistas y controladores. Reconocerlo exige conservar esa escala: equipos que prepararon capacidades de recuperación y personas que decidieron apoyándose en el comportamiento observado.

Dar al software el peso de una decisión de ingeniería

Hamilton defendió el término ingeniería del software para reclamar legitimidad y consideración profesional para ese trabajo. NASA la reconoce por contribuir a popularizar el concepto. La aportación que merece atención va más allá de adjudicar la primera aparición de dos palabras: situar el software junto a las demás disciplinas que determinan si un sistema cumple su cometido.

La elección del nombre tiene una consecuencia organizativa. Si el software se trata como un detalle que llegará después de diseñar el producto, sus límites aparecen tarde. Si participa desde el principio, puede cuestionar requisitos incompatibles, reclamar pruebas y explicar qué comportamiento resulta viable con los recursos disponibles.

Eso sigue siendo una discusión reconocible en una empresa. Una fecha de entrega puede estar cerrada mientras quedan sin decidir el comportamiento ante una caída, la reconciliación de datos o quién tiene autoridad para detener una operación. El resultado puede funcionar durante una demostración y mantener abiertas preguntas esenciales para su uso real.

Hamilton también trabajó en la interacción entre el software y el astronauta. El Computer History Museum destaca sus Priority Displays, mecanismos de detección y recuperación que permitían comunicar situaciones prioritarias al operador. Esta es una contribución específica a la relación entre persona y sistema; no debe confundirse automáticamente con toda la arquitectura ejecutiva ni con una explicación única de las alarmas del alunizaje.

Una señal útil necesita llegar a quien puede decidir y permitirle comprender qué está en juego. Mostrar un error es solo una parte de ese trabajo. En un sistema actual, también importa distinguir qué dejó de funcionar, qué permanece fiable y qué intervención tiene sentido.

Después de Apollo: prevenir errores desde el diseño

Su trayectoria continuó fuera del programa espacial. Según el recorrido profesional publicado por el MIT, creó Higher Order Software en 1976 y Hamilton Technologies una década después. Esta última desarrolló Universal Systems Language, una propuesta de modelado de sistemas orientada a la prevención de errores.

Es una continuidad significativa: intentar que las relaciones y decisiones del sistema estén suficientemente definidas antes de convertirse en fallos de ejecución. No hace falta presentar esa metodología como solución universal ni atribuirle una adopción que estas fuentes no demuestran para reconocer la ambición del problema.

El MIT comunicó el 7 de octubre de 2026 su fallecimiento, ocurrido el 30 de septiembre. La noticia invita a volver a una trayectoria cuyo valor profesional permanece en preguntas muy concretas: qué hemos previsto, qué hemos probado y quién responde por lo que falta.

Su visibilidad como mujer al frente de trabajo técnico también amplió los referentes disponibles para quienes se incorporaban a la profesión. La mejor forma de mantener ese reconocimiento es explicar las decisiones, responsabilidades y contribuciones que sostuvo, además de mostrar su fotografía.

Una ficha para discutir qué debe sobrevivir a un fallo

Propongo una ficha de continuidad esencial para llevar esta lectura histórica a una conversación de diseño. Es una síntesis propia, no un método de Hamilton, una norma aeroespacial ni una certificación de seguridad. Su utilidad consiste en hacer visibles decisiones que suelen quedar dispersas.

Compromiso que debe conservarse

El resultado que el sistema debe proteger cuando pierde capacidad. Debe describirse desde la operación: por ejemplo, conservar un pedido aceptado y su estado.

Trabajo que puede esperar

Funciones que admiten demora o suspensión y el efecto que esa degradación tendrá para la persona usuaria.

Estado necesario para recuperar

Información que permitirá saber dónde continuar, qué quedó pendiente y qué acciones ya produjeron efectos.

Evidencia y autoridad

Pruebas que respaldan el comportamiento esperado, señales disponibles durante el incidente y quién puede continuar, limitar o detener la operación.

Imaginemos una plataforma de pedidos: es un ejemplo hipotético, no una descripción de un cliente. Durante una sobrecarga podría retrasar recomendaciones y estadísticas para proteger la aceptación de pedidos. Pero esa preferencia solo sirve si los componentes permiten aplicarla. Declarar que todo es «crítico» deja la decisión en manos de la contención accidental de recursos.

La recuperación abre otra pregunta. Si se pierde una respuesta después de cobrar, volver al principio puede duplicar el cargo. En el artículo sobre timeouts y reintentos de operaciones explicábamos por qué un resultado desconocido necesita tratamiento propio. La ficha obliga a identificar qué estado permite resolver esa incertidumbre antes de repetir.

Existe un límite importante en la analogía: una plataforma comercial y una nave tripulada tienen consecuencias y exigencias distintas. En algunos sistemas será aceptable reducir prestaciones; en otros, el comportamiento correcto será detenerse de manera controlada. La historia de Apollo no concede permiso para seguir adelante cada vez que aparece una alarma. Invita a exigir fundamento para esa decisión.

El reconocimiento más útil a Margaret Hamilton puede expresarse así: conceder a quienes construyen software la responsabilidad, los medios y la autoridad necesarios para discutir estas condiciones antes de entregar. El siguiente incidente pondrá a prueba tanto el programa como las decisiones que la organización tomó mientras todavía había tiempo.