Filosofía de la ingeniería: Margaret Hamilton

Ideas clave

• Acuñó el término «software engineering» para ganarle a la disciplina su legitimidad. Mientras lideraba el esfuerzo del software de vuelo del Apolo en el MIT Instrumentation Laboratory, Margaret Hamilton empezó a llamar a ese trabajo «software engineering»: lo hizo de forma deliberada, para sostener que escribir el código que llevaba personas a la Luna merecía el mismo rigor y respeto que la ingeniería de hardware y de sistemas, en una época en que el software se trataba como algo secundario.¹²
• Su software salvó el alunizaje del Apolo 11 cuando la computadora de guiado lanzó las alarmas 1202 y 1201. Durante el descenso final, un interruptor del radar de encuentro mal configurado le dio a la Apollo Guidance Computer trabajo espurio que nunca debió haber tenido, y al ejecutivo se le acabó la memoria para programarlo: las célebres alarmas 1202 («no core sets») y 1201 («no VAC areas»). Como el equipo de Hamilton había construido el software con programación por prioridades y protección de reinicio, la computadora descartó las tareas de radar de baja prioridad, mantuvo en marcha el guiado crítico para el alunizaje, y el descenso tuvo éxito.³⁴⁵
• Su compromiso definitorio es el diseño defensivo: diseñar para el caso de fallo, porque no hay una segunda oportunidad. «No había una segunda oportunidad. Lo sabíamos», dijo sobre el Apolo.² La detección de errores, la recuperación, la programación asíncrona por prioridades y las pantallas con el humano en el circuito no eran funciones añadidas después de que el camino feliz funcionara: eran el centro del diseño, la razón por la que el software se degradaba con elegancia en lugar de colapsar.⁶
• Construyó la corrección desde el principio: «Development Before the Fact». Después del Apolo fundó Higher Order Software (1976) y Hamilton Technologies (1986), donde desarrolló el Universal Systems Language (USL) y una metodología para diseñar sistemas de modo que clases enteras de error fueran imposibles por construcción, en lugar de detectarse mediante pruebas. Recibió el NASA Exceptional Space Act Award (2003) y la Medalla Presidencial de la Libertad (2016).¹⁶

El principio

«No había una segunda oportunidad. Lo sabíamos. Nos tomábamos nuestro trabajo en serio; muchos empezamos este camino cuando todavía teníamos veintipocos años.» – Margaret Hamilton, sobre el software de vuelo del Apolo²

Casi toda la ingeniería se optimiza para el caso en que todo funciona. Construyes el camino feliz, manejas unos cuantos errores que alcanzas a imaginar y publicas; y cuando algo se rompe en producción, lo parcheas y vuelves a desplegar. Ese ciclo es la comodidad dentro de la cual vive casi todo el software: el fallo es recuperable porque siempre hay una próxima oportunidad. El trabajo de Hamilton partía de la premisa opuesta. El software que ella lideraba iba a llevar a tres personas a un cuarto de millón de kilómetros de la Tierra y a posar a dos de ellas sobre la Luna, y no había parche, ni nuevo despliegue, ni próxima oportunidad. Tenía que funcionar a la primera, en condiciones que nadie podía ensayar del todo, en una computadora con menos memoria que una tarjeta de felicitación que reproduce una melodía.² Cuando el costo de un solo error no detectado es la tripulación, «diseñar para el caso de fallo» deja de ser un buen consejo y se convierte en el trabajo entero.

El principio que se desprende es el diseño defensivo como centro del diseño, no como limpieza posterior. Si el software debe sobrevivir a lo inesperado, entonces detectar errores, recuperarse de ellos y degradarse con elegancia no pueden ser funciones que añades una vez que el camino que funciona está listo: tienen que ser el esqueleto del que ese camino cuelga. El equipo de Hamilton construyó el software del Apolo para que la computadora pudiera darse cuenta de que se le pedía más de lo que podía, descartar el trabajo que no importaba, reiniciar limpiamente a un estado conocido como bueno y seguir haciendo lo único que mataría a la tripulación si se detuviera. El sistema no se construyó para evitar todos los fallos: en una máquina tan pequeña, frente a una misión tan implacable, no se puede. Se construyó para que, cuando llegara el fallo, ese fallo fuera sobrevivible.³⁶

Hay una segunda mitad del principio, y es la que vuelve real a la primera: construir la corrección desde el principio en lugar de eliminar los errores con pruebas al final. Detectar un error y recuperarse de él en tiempo de ejecución es la última línea de defensa; la disciplina más profunda consiste en diseñar el sistema de modo que categorías enteras de error no puedan ocurrir siquiera. Hamilton dedicó la segunda mitad de su carrera a formalizar exactamente esto: una metodología que llamó «Development Before the Fact» y un lenguaje creado para hacer que los errores de interfaz fueran estructuralmente imposibles.⁶ Las dos mitades son una sola idea vista desde dos distancias: cuando no hay segunda oportunidad, defiendes en tiempo de ejecución y haces que el fallo sea irrepresentable en tiempo de diseño, porque el único error en el que puedes confiar plenamente es el que el sistema nunca fue capaz de cometer.

Contexto

Margaret Hamilton nació como Margaret Heafield el 17 de agosto de 1936, en Paoli, Indiana.¹ Estudió matemáticas en Earlham College, donde se graduó en 1958 con una especialización menor en filosofía: una combinación que reaparece más tarde en su forma de pensar los sistemas, no solo el código.¹ No llegó al Apolo a través de una formación en ciencias de la computación, porque a finales de los años cincuenta no existía tal cosa; llegó a través de las matemáticas y del propio trabajo.

Su primera programación fue real y de altas consecuencias desde el inicio. En 1959 empezó a trabajar en el departamento de meteorología del MIT con Edward Lorenz —el fundador de la teoría del caos—, escribiendo software de predicción meteorológica en la LGP-30 y la PDP-1.¹ Entre 1961 y 1963, aproximadamente, trabajó en el proyecto SAGE en el MIT Lincoln Laboratory, escribiendo software para la computadora AN/FSQ-7 que la Fuerza Aérea de los Estados Unidos usaba para detectar aeronaves entrantes.¹ SAGE fue uno de los primeros sistemas de software grandes en tiempo real y sensibles a fallos jamás construidos, y la reputación que se ganó allí —por asumir el código más difícil y más propenso a fallar— es lo que la llevó al Apolo.

En 1965 se incorporó al MIT Instrumentation Laboratory (más tarde Draper Lab), que tenía el contrato para construir el software de vuelo a bordo del programa Apolo de la NASA. Ascendió hasta dirigir la Software Engineering Division, al frente del equipo responsable del software de vuelo a bordo que corría en la Apollo Guidance Computer, tanto en el módulo de mando como en el módulo lunar.¹ Fue aquí, en medio de ese trabajo, donde empezó a usar el término «software engineering», no como una palabra de moda, sino como un argumento. Como ella misma lo planteó, usó el término «para distinguirlo del hardware y de otros tipos de ingeniería, y a la vez tratar cada tipo de ingeniería como parte del proceso general de ingeniería de sistemas».¹ El software, insistía, era una disciplina que merecía un nombre y el rigor que viene con él. Después del Apolo fundó Higher Order Software en 1976 y Hamilton Technologies en 1986, donde desarrolló el Universal Systems Language y la metodología «Development Before the Fact».¹⁶

El trabajo

La alarma 1202 del Apolo 11: programación por prioridades y protección de reinicio

Empecemos por aquí, porque es el principio hecho mecanismo bajo la peor presión posible. La Apollo Guidance Computer era una máquina diminuta —unas pocas decenas de kilobytes de memoria, sin sistema operativo en el sentido moderno— que corría un ejecutivo en tiempo real diseñado por el equipo de Hamilton. Para ejecutar una tarea, el ejecutivo tenía que encontrar memoria libre: un «core set» (un bloque pequeño para el estado de la tarea) y, para las tareas que hacían cálculos de coma flotante, un «VAC area».⁴ Si se programaba una tarea y no había ningún core set libre, el ejecutivo saltaba a su rutina de alarma y levantaba la alarma 1202; si no había ningún VAC area libre, levantaba la 1201.⁴ No eran códigos de colapso. Eran el ejecutivo anunciando que se le había pedido más de lo que tenía capacidad para hacer, y luego haciendo algo al respecto.

Durante los minutos finales del descenso del Apolo 11, eso es exactamente lo que ocurrió. La lista de verificación de los astronautas hacía que la tripulación dejara el interruptor del radar de encuentro en la posición incorrecta, lo que provocaba que el radar robara ciclos del procesador e hiciera que el ejecutivo programara repetidamente tareas de procesamiento de datos que nunca debieron estar corriendo.³⁴ El trabajo espurio consumió toda la memoria libre, y se disparó la alarma 1202; luego se disparó otra vez, y también la 1201, cuatro veces en los segundos previos al contacto con la superficie. Una computadora ingenua a la que se le pide hacer todo habría intentado hacer todo, se habría quedado atrás en la única tarea que importaba y se habría congelado. La de Hamilton no.

Dos decisiones de diseño salvaron el alunizaje. La primera fue la programación por prioridades: el ejecutivo corría las tareas por prioridad y podía descartar el trabajo de menor prioridad, de modo que el guiado crítico para el alunizaje y la pantalla de la tripulación (DSKY) siempre corrían mientras las tareas basura del radar quedaban sin recursos.³⁵ La segunda fue la protección de reinicio: cada alarma disparaba un reinicio por software que limpiaba la cola de tareas sobrecargada y rearrancaba en un estado conocido como bueno, reiniciando «lo importante, como dirigir el motor de descenso y correr el DSKY», pero sin reiniciar las tareas de radar programadas por error.⁴⁵ La computadora descartó efectivamente el ruido, siguió pilotando la nave y le avisó a la tripulación que lo estaba manejando, que es por lo que el Control de la Misión pudo dar el «adelante» ante una alarma que, en un diseño inferior, habría significado abortar.

Por qué importa como ingeniería: la alarma no era el fallo, era el manejo del fallo funcionando como se había diseñado. El equipo había construido el ejecutivo para esperar la sobrecarga, para hacer triaje bajo ella y para recuperarse de ella, y habían probado esa recuperación de forma tan exhaustiva que los controladores confiaron en ella bajo la mayor presión a la que se haya sometido jamás cualquier software. Esa es toda la doctrina en un solo momento: el fallo se daba por supuesto, el caso de fallo era el centro del diseño, y el sistema se degradaba a «hacer solo lo que mantiene viva a la tripulación» en lugar de venirse abajo. El mismo instinto vive hoy en cada cola de prioridades que descarta carga, en cada supervisor que reinicia un trabajador caído a un estado limpio, en cada sistema construido para sobrevivir a ser desbordado.

Acuñar «software engineering» y la lucha por la legitimidad

La historia de la 1202 es famosa; el nombramiento es, sin duda, más trascendente. En los años sesenta, el software se trataba en general como el hermano blando y poco serio de la ingeniería «de verdad»: algo que resolvías después de diseñar el hardware, no una disciplina con su propio rigor. Hamilton rechazó ese encuadre. Dentro del Apolo empezó a llamar deliberadamente al trabajo «software engineering», y fue explícita sobre el porqué: para «distinguirlo del hardware y de otros tipos de ingeniería, y a la vez tratar cada tipo de ingeniería como parte del proceso general de ingeniería de sistemas».¹ El punto no era el vocabulario. El punto era el estatus. Si el código que volaba la misión era ingeniería, entonces merecía la disciplina de la ingeniería: especificaciones, revisiones, pruebas, trazabilidad y la expectativa de que se hiciera correcto, no apenas que funcionara.

Ella ha contado que al principio el término fue recibido con cierta sorna: la idea de que el software pudiera ser «ingeniería» a la gente le parecía exagerada.¹ Pero la legitimidad por la que peleaba era estructural. No puedes exigirle a un equipo que diseñe para el caso de fallo, que integre la recuperación de errores en los huesos de un sistema y que trate la corrección como innegociable si el trabajo se considera scripting casual que alguien limpiará después. Nombrar la disciplina era la condición previa para exigirle un estándar. Para finales de la década el término había escapado del MIT y se había convertido en el nombre de un campo; hoy «software engineering» es tan ordinario que resulta invisible, que es la señal más segura de que el argumento se ganó.¹²

Diseño defensivo: el «error de Lauren» y diseñar frente al humano

Si quieres la ventana más clara a cómo pensaba Hamilton, es el «error de Lauren». Su pequeña hija Lauren a veces iba al laboratorio y jugaba a ser astronauta en el simulador del módulo de mando, y un día lo hizo colapsar: seleccionó P01, el programa de prelanzamiento, mientras la nave simulada ya estaba en pleno vuelo hacia la Luna.⁷ Cargar la inicialización de prelanzamiento a mitad de trayecto borró los datos de navegación y dejó perdida a la computadora. El instinto de Hamilton no fue «ningún astronauta haría jamás eso». Fue: si el simulador dejó que una niña lo hiciera, el software lo permitió, y todo lo que el software permite acabará por suceder. Propuso agregar código de detección de errores para impedir que se seleccionara P01 en vuelo.⁷

La rechazaron —le dijeron que los astronautas eran profesionales entrenados que jamás cometerían semejante error— y solo le permitieron agregar una nota a la documentación.⁷ Entonces, en la siguiente misión, el Apolo 8, Jim Lovell hizo exactamente lo que Lauren había hecho: seleccionó P01 a mitad de vuelo y borró los datos de navegación en el primer viaje de la humanidad alrededor de la Luna.⁷ Después de eso, la corrección se incorporó. La lección que Hamilton extrajo, y repitió, es el corazón del diseño defensivo: no puedes decidir que un fallo «no puede pasar» y diseñar como si no fuera a pasar. El astronauta, el interruptor del radar, el operador a las 3 de la madrugada: el sistema tiene que ser robusto frente al humano en el circuito, no quedar protegido de la culpa suponiendo que el humano será perfecto. Sus pantallas por prioridades encarnaban la misma idea desde la otra dirección: mantener al humano informado y al mando, de modo que cuando la computadora hiciera triaje bajo la sobrecarga, la tripulación entendiera qué estaba haciendo y pudiera decidir.⁶

Higher Order Software, USL y «Development Before the Fact»

El Apolo le enseñó a Hamilton de dónde vienen los errores, y dedicó el resto de su carrera a atacarlos en la raíz. Al estudiar los errores del Apolo, observó que una gran parte de ellos no vivía dentro de los módulos individuales, sino en las interfaces entre ellos: los lugares donde una pieza de software le entregaba datos a otra y los supuestos no encajaban del todo. En Higher Order Software (1976) y luego en Hamilton Technologies (1986), construyó un cuerpo de trabajo en torno a eliminar esos errores por construcción en lugar de atraparlos mediante pruebas.¹⁶

La metodología se llama «Development Before the Fact». El nombre es la tesis: en lugar de construir un sistema y luego cazar defectos a posteriori, lo defines —usando un sistema formal, el Universal Systems Language (USL)— con tanto rigor que clases enteras de error, en especial los de interfaz e integración, resultan estructuralmente imposibles. El modelo es demostrablemente consistente, y a partir de él puede generarse código correcto, de modo que el defecto se previene en tiempo de diseño en vez de descubrirse en tiempo de ejecución.⁶ Es la misma convicción que el ejecutivo del Apolo, llevada un nivel más profundo: la recuperación en tiempo de ejecución es la red de seguridad, pero la verdadera victoria es un sistema que nunca fue capaz de cometer el error en primer lugar. Buena parte de la industria todavía corre el ciclo opuesto —publicar, encontrar errores, parchear—, que es justo el ciclo que Hamilton pasó treinta años sosteniendo que estaba al revés cuando la corrección de verdad importa.

El método

Si lees de corrido el ejecutivo del Apolo, la acuñación de «software engineering», el error de Lauren y «Development Before the Fact», reaparecen los mismos compromisos. El método de Hamilton es menos un lema que un conjunto de hábitos permanentes.

Diseña primero para el caso de fallo: no hay una segunda oportunidad. El ejecutivo del Apolo no era un planificador con manejo de sobrecarga añadido encima; sobrevivir a la sobrecarga era el diseño, porque una computadora congelada sobre la Luna mataba a la tripulación.³⁴ La lección trasciende con creces los vuelos espaciales: enumera cómo falla el sistema antes de escribir el camino en que funciona, y deja que el camino que funciona se desprenda de una estructura que ya sobrevive a los fallos. Es la puerta de la evidencia aplicada a la fiabilidad —«funciona en el simulador» no es evidencia; «descarta carga y sigue volando cuando el radar lo inunda» sí lo es—, el mismo estándar de degradación elegante que Werner Vogels convirtió en la premisa fundacional de la nube décadas más tarde.

Supón que el humano hará lo imposible. El error de Lauren es la regla en miniatura: si el sistema permite una acción peligrosa, alguien —una niña, un astronauta, un operador cansado— acabará por ejecutarla, así que «nadie haría jamás eso» no es una defensa.⁷ El hábito permanente es proteger la frontera frente a la entrada que te aseguraron que jamás llegaría, porque los fallos que más duelen son los que decidiste de antemano que no podían pasar. Es el mismo instinto de robustez frente al adversario que Radia Perlman integró en un enrutamiento que se mantiene correcto incluso cuando los nodos mienten.

Haz triaje bajo carga: descarta lo irrelevante, protege lo crítico. Cuando el ejecutivo se quedó sin memoria, no intentó atender cada solicitud; corrió las tareas de mayor prioridad y dejó sin recursos al resto, y luego reinició limpio.³⁵ La disciplina consiste en decidir de antemano cuál es la única cosa que jamás debe detenerse, y en construir el sistema de modo que bajo presión sacrifique todo lo demás para mantener esa única cosa en marcha. Un sistema sin prioridades es un sistema que falla en el peor momento porque trató a la pantalla de la tripulación y a la tarea basura del radar como iguales.

Construye la corrección dentro, no la pruebes para meterla. «Development Before the Fact» es el rechazo del ciclo publicar-y-depurar: define el sistema de modo que el error no pueda expresarse, en lugar de construirlo y cazar el error después.⁶ La lección es que el defecto más barato y más confiable es el que el diseño hizo imposible: la misma convicción que Barbara Liskov convirtió en disciplina de tipos y abstracción, y que Leslie Lamport convirtió en especificar la corrección con precisión antes de escribir el código. Es la calidad es la única variable hecha flujo de trabajo: la corrección no es una fase al final, es la forma de la cosa desde el principio.

Nombra la disciplina para poder exigirle un estándar. Llamar al trabajo «software engineering» fue el acto que habilitó todo lo demás: especificaciones, revisiones, la expectativa de rigor.¹ El hábito permanente es insistir en que el trabajo tenga un nombre y un estándar, porque no puedes exigir oficio a algo que la organización considera desechable. Es el espíritu del producto mínimo digno: la cosa vale la pena hacerla bien, así que la haces bien, y argumentas en voz alta que bien es la única manera aceptable.

Cadena de influencia

Quiénes la formaron

La tradición de matemáticas y tiempo real en el MIT. Hamilton se formó a través de las matemáticas y de SAGE —uno de los primeros sistemas de software grandes en tiempo real y sensibles a fallos— y del modelado meteorológico con Edward Lorenz, el fundador de la teoría del caos.¹ Esa base se nota: pensaba el software como un sistema que tenía que mantenerse correcto en condiciones que nadie podía predecir del todo, mucho antes de llegar al Apolo. (Influencia formativa)

La disciplina implacable del propio vuelo espacial. La misión Apolo fue tan maestra como cualquier persona. Un dominio donde un solo error cuesta la tripulación, donde no hay parche ni segunda oportunidad, impone una forma de trabajar —defender el caso de fallo, recuperarse en tiempo de ejecución, prevenir el error en tiempo de diseño— que el software ordinario nunca exige.² La restricción dio forma a la filosofía. (Influencia directa)

La cultura de ingeniería de sistemas del programa Apolo. Trabajar dentro de un programa donde su software tenía que integrarse con el hardware, el control de la misión y el procedimiento humano la empujó a ver el software como una disciplina de ingeniería entre varias, que es justo el encuadre detrás de su acuñación de «software engineering» como parte del «proceso general de ingeniería de sistemas».¹ (Influencia formativa)

A quiénes formó ella

A la propia disciplina de la ingeniería de software. Al nombrar el campo y defender su rigor desde dentro del proyecto de software de mayores consecuencias de su época, Hamilton ayudó a convertir la programación de un añadido secundario en una disciplina de ingeniería con especificaciones, revisiones y la expectativa de corrección.¹²

A todo sistema de tiempo real tolerante a fallos. La programación por prioridades, el descarte de carga, el reinicio a un estado conocido como bueno y las pantallas con el humano en el circuito —los patrones que el ejecutivo del Apolo usó para sobrevivir a la alarma 1202— son hoy el vocabulario estándar de los sistemas resilientes, desde el control de vuelo hasta los supervisores que mantienen vivos los servicios web bajo sobrecarga.³⁶

A los métodos formales, correctos por construcción. «Development Before the Fact» y el Universal Systems Language forman parte del linaje que sostiene que la corrección debe diseñarse desde dentro y ser demostrable, no probarse a posteriori: un argumento que recorre los métodos formales y el desarrollo dirigido por modelos hasta hoy.⁶

El hilo conductor

Hamilton es el punto de origen del linaje de la fiabilidad en esta serie: el lugar donde «diseñar para el caso de fallo» dejó de ser una preferencia y se volvió innegociable, porque había vidas en juego, décadas antes de que el resto del campo lo alcanzara. Werner Vogels construyó la nube sobre «todo falla todo el tiempo» y diseñó para la degradación elegante a escala planetaria; Hamilton diseñó para la degradación elegante en una computadora del tamaño de un maletín, con una tripulación encima, y demostró que la doctrina funciona cuando de verdad no hay segunda oportunidad.³ Radia Perlman construyó redes que se sanan a sí mismas y se mantienen correctas incluso cuando los nodos mienten; el ejecutivo de Hamilton se sanó a sí mismo en tiempo real sobre la Luna, rearrancando limpio y descartando las mentiras que le daba el radar averiado.⁴ Y Leslie Lamport hizo de la corrección algo que defines con precisión y demuestras antes de construir, que es exactamente lo que busca «Development Before the Fact», una generación antes y apuntando al mismo blanco.⁶ Donde Vogels dice todo falla, así que mantente disponible a pesar de ello y Perlman dice constrúyelo para que se sane solo, Hamilton lo dijo primero y con más fuerza: no hay una segunda oportunidad, así que diseña para el fallo antes de que ocurra, recupérate de él cuando ocurra, y construye el sistema de modo que los peores errores nunca hayan sido siquiera posibles. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo de Hamilton es construir como si no hubiera una segunda oportunidad, incluso cuando es obvio que sí la hay. Casi todo lo que publico vive dentro de la comodidad que ella no tuvo: si se rompe, empujo una corrección. Esa red de seguridad es real, y silenciosamente baja el listón: me deja publicar el camino feliz y decirme que ya manejaré el caso de fallo más tarde, porque ese «más tarde» existe. El Apolo es el reproche. Cuando de verdad no puedes parchearlo, descubres que «manejar el fallo más tarde» nunca fue ingeniería siquiera; el caso de fallo es la ingeniería, y el camino que funciona es solo lo que queda una vez que el sistema ya sobrevive a estar roto. Así que cuando construyo algo ahora —una tarea que puede inundarse, una API que puede invocarse mal, un camino que puede tomarse en el momento equivocado— intento preguntarme «¿cuál es aquí el interruptor del radar en la posición incorrecta, y esto lo descarta y sigue volando?» antes de preguntarme si el camino feliz funciona. Un sistema que solo sobrevive a la entrada correcta es un sistema que no he terminado.

La segunda lección es que el error más confiable es el que el diseño hizo imposible. El error de Lauren se me queda grabado porque Hamilton tenía razón y la dejaron en minoría con un «nadie haría jamás eso», y el universo hizo exactamente eso de inmediato, en la siguiente misión. Mi instinto es atrapar los errores en tiempo de ejecución, envolver la llamada peligrosa en una protección y seguir adelante. El movimiento más profundo de Hamilton, ese al que dedicó treinta años, es diseñar el sistema de modo que la llamada peligrosa no pueda hacerse: volver el mal estado irrepresentable en lugar de meramente detectado. La recuperación en tiempo de ejecución es la red; construir la corrección desde dentro es el suelo sobre el que te paras para no necesitar la red. No siempre alcanzo ese listón, pero reformuló la meta: la pregunta no es solo «¿lo atraparé cuando salga mal?», sino «¿puedo darle forma a esto para que no pueda salir mal en primer lugar?»; y la segunda pregunta, cuando puedo responderla, siempre es la mejor.

Preguntas frecuentes

¿Acuñó Margaret Hamilton el término «software engineering»?

A Margaret Hamilton se le atribuye ampliamente haber acuñado —o al menos popularizado— el término «software engineering», que empezó a usar mientras lideraba el esfuerzo del software de vuelo del Apolo en el MIT Instrumentation Laboratory en los años sesenta.¹² Lo usó de forma deliberada para sostener que escribir software merecía la misma legitimidad y rigor que el hardware y otras disciplinas de ingeniería, explicando que quería «distinguirlo del hardware y de otros tipos de ingeniería, y a la vez tratar cada tipo de ingeniería como parte del proceso general de ingeniería de sistemas».¹ En su momento, la idea de que el software pudiera ser «ingeniería» fue recibida con cierta sorna; hoy el término es tan estándar que resulta invisible, que es la medida de cuán a fondo se ganó el argumento.¹

¿Qué fueron las alarmas 1202 y 1201 durante el Apolo 11?

Fueron alarmas de programa que levantó el ejecutivo de la Apollo Guidance Computer durante los minutos finales del descenso lunar. Un interruptor del radar de encuentro mal configurado provocó que el radar robara ciclos del procesador e hiciera que el ejecutivo programara repetidamente tareas de procesamiento de datos que no debían estar corriendo, lo que consumió toda la memoria libre.³⁴ Cuando no había ningún «core set» de memoria disponible, el ejecutivo levantaba la alarma 1202; cuando no había ningún «VAC area» disponible, levantaba la 1201.⁴ Las alarmas no eran colapsos: eran el ejecutivo informando que se le había pedido más de lo que podía y haciendo triaje a continuación. Como el software usaba programación por prioridades y protección de reinicio, descartó las tareas de radar espurias, rearrancó a un estado conocido como bueno, mantuvo corriendo el guiado crítico para el alunizaje y la pantalla de la tripulación, y el descenso tuvo éxito.³⁵

¿Qué hizo Margaret Hamilton para el programa Apolo?

Hamilton se incorporó al MIT Instrumentation Laboratory en 1965 y ascendió hasta dirigir la Software Engineering Division responsable del software de vuelo a bordo que corría en la Apollo Guidance Computer, tanto en el módulo de mando como en el módulo lunar.¹ Su equipo diseñó el ejecutivo en tiempo real con programación asíncrona por prioridades, protección de reinicio, detección y recuperación de errores y pantallas por prioridades que mantenían a los astronautas informados y al mando: la arquitectura que permitió que la computadora del Apolo 11 sobreviviera a la alarma 1202 y completara el alunizaje.³⁶ La mención de su Medalla Presidencial de la Libertad le atribuye haber aportado «conceptos de software asíncrono, programación por prioridades y pantallas por prioridades, y capacidad de decisión con el humano en el circuito, que sentaron las bases del diseño y la ingeniería de software modernos y ultrafiables».⁶

¿Qué es «Development Before the Fact»?

«Development Before the Fact» es la metodología de sistemas que Hamilton desarrolló en Higher Order Software y Hamilton Technologies después del Apolo, construida en torno a su Universal Systems Language (USL).¹⁶ Su tesis es que, en lugar de construir un sistema y luego cazar defectos «a posteriori» mediante pruebas, defines el sistema con tanto rigor y formalidad que clases enteras de error —en especial los de interfaz e integración que, según descubrió, dominaban los defectos del Apolo— resultan estructuralmente imposibles por construcción.⁶ El modelo es demostrablemente consistente y a partir de él puede generarse código correcto, de modo que el defecto se previene en tiempo de diseño en lugar de descubrirse en tiempo de ejecución. Es la expresión, en términos de métodos formales, de su convicción del Apolo: el error más confiable es el que el sistema nunca fue capaz de cometer.

Fuentes