O DANI GEEK

Margaret Hamilton (1936–2026): o software da Apollo foi projetado para o erro, não para a demo

O Dani Geek — arte original

Ela morreu em 30 de setembro, aos 90 anos, e o MIT anunciou em 7 de outubro. Além da foto da pilha de listagens, o que sobra do trabalho dela é a tese de que sistema que funciona é sistema desenhado para o momento em que algo dá errado.

A cronologia

Margaret Hamilton morreu em 30 de setembro de 2026, num hospital em Cambridge, Massachusetts, aos 90 anos. O MIT anunciou a morte em 7 de outubro (MIT News), e a imprensa brasileira publicou no dia 8 (O Tempo, CartaCapital), mesmo dia em que a morte foi noticiada nos Estados Unidos (NPR). A causa não foi divulgada por nenhuma das fontes.

Nasceu em 17 de agosto de 1936, em Indiana. Formou-se em matemática no Earlham College em 1958 e entrou no MIT em 1959, quando a palavra “software” ainda não designava uma profissão (WBUR).

Ela nunca foi funcionária da NASA

O atalho que circula é “cientista da NASA”. A manchete da CartaCapital a põe como “cientista do programa Apollo da Nasa”. Hamilton nunca foi funcionária da NASA: trabalhou no MIT Instrumentation Laboratory, que tinha o contrato da NASA para o software de bordo da Apollo.

A distinção importa porque explica o resto da história. Ela não estava dentro da agência que decidia; estava no fornecedor que entregava, com a liberdade e a exposição que isso traz. Em 1968 era assistente de direção da equipe do Módulo de Comando/Serviço, e liderava o time de engenharia de software do laboratório. Naquele ano, segundo o MIT, mais de 400 pessoas trabalhavam no software da Apollo.

A liberdade tinha uma razão prática e meio engraçada, que ela mesma contou: “Como o software era um mistério, uma caixa-preta, a alta direção nos deu total liberdade e confiança” (“Because software was a mystery, a black box, upper management gave us total freedom and trust”, ao WBUR). Ninguém sabia o suficiente para microgerenciar o trabalho dela.

O erro da Lauren, e a Apollo 8

A parte da história que vale copiar aconteceu antes do pouso.

Lauren, filha de Hamilton, tinha 4 anos e brincava no simulador enquanto a mãe trabalhava. Em algum momento a menina acionou por acidente o programa P01, previsto para a fase de pré-lançamento, durante uma simulação de voo. A simulação quebrou.

Hamilton documentou o caso e propôs uma trava em software para impedir que um operador chamasse o P01 fora de hora. Foi vetada: astronauta treinado não comete esse erro. O mesmo erro aconteceu de verdade na Apollo 8, em voo, com Jim Lovell acionando o P01 e apagando os dados de navegação (MIT News).

Uma criança de 4 anos produziu, em ambiente de teste, um cenário que a sala considerou impossível. A sala decidiu em cima de uma premissa sobre o usuário. A premissa estava errada e o custo apareceu a 300 mil quilômetros da Terra.

O 1202 não foi sorte

Na descida da Apollo 11, o computador de bordo soltou o alarme 1202: sobrecarga. Tinha mais tarefa pedindo processamento do que a máquina conseguia executar.

O software não travou e não escolheu ao acaso o que abandonar. Projetado com escalonamento por prioridade, ele derrubou automaticamente as tarefas não essenciais e preservou as funções críticas do pouso (MIT News). O módulo lunar desceu.

Essa é a diferença entre um sistema que aguenta e um sistema que dá sorte: alguém, meses antes, na mesa de projeto, declarou o que era descartável, em vez de deixar essa decisão para o momento da crise.

Sobre o mecanismo por trás disso (a arquitetura de execução assíncrona do computador de bordo, os displays de prioridade, a diferença exata entre os alarmes 1201 e 1202), as fontes lidas aqui não dão detalhe suficiente para descrever com precisão. Fica como leitura seguinte, na documentação do Apollo Guidance Computer e nos relatos de quem escreveu o código do pouso.

Traduzindo para 2026

Programação defensiva, como ela chamava, era programar assumindo que a máquina e a pessoa vão errar.

Olhe os fluxos de IA que circulam hoje, incluindo boa parte do que se publica como tutorial. Quase todos mostram o caminho feliz: o prompt bonito, a resposta perfeita colada na planilha. Pergunte do resto:

Na prática, a tese da Hamilton vira três coisas verificáveis no seu setup. Prioridade declarada: você escreveu em algum lugar o que o sistema sacrifica sob pressão, ou isso vai ser decidido às 2h da manhã por quem estiver acordado. Degradação visível: quando um passo falha, o fluxo para e avisa, em vez de seguir com dado pela metade. Teste no caminho torto: antes de publicar o tutorial, você rodou com o input errado, o arquivo vazio, o campo colado no lugar errado.

Aqui dentro a regra tem um nome mais seco: um fluxo que só foi testado com a entrada certa não foi testado.

Nomear a prática é o que permite cobrar um padrão

Hamilton cunhou o termo “software engineering”, e cunhou de propósito. Em 2018 explicou por quê: “Eu lutei para dar legitimidade ao software, para que ele [e quem o constrói] recebesse o respeito devido” (“I fought to bring the software legitimacy so that it [and those building it] would be given its due respect”, citado pela MIT News).

Na época, chamar aquilo de engenharia soou pretensioso para muita gente. Era exatamente o ponto: engenharia tem método, revisão, responsabilidade por falha. Dar o nome criou a expectativa de que a prática fosse cobrada por um padrão.

Vale guardar isso na próxima vez que a discussão sobre “engenheiro de prompt”, “engenheiro de IA” ou “agente” for descartada como marketing. Pode ser marketing. Também pode ser o começo da parte em que alguém passa a ter que responder quando a coisa quebra.

O reconhecimento veio aos 80

Depois da Apollo, Hamilton seguiu construindo em vez de virar palestrante de legado. Fundou a Higher Order Software em 1976 e, nos anos 1980, a Hamilton Technologies, cujo produto principal foi a USL (Universal Systems Language), uma linguagem de modelagem de sistemas complexos com prevenção de erro no centro (MIT News). Foram trinta anos construindo em cima da mesma tese.

O reconhecimento público chegou tarde. NASA Exceptional Space Act Award em 2003. A Medalha Presidencial da Liberdade em 2016, aos 80 anos, quando Barack Obama disse que o trabalho dela “helped launch an industry that would forever change human history” (ajudou a lançar uma indústria que mudaria a história humana para sempre), segundo a MIT News. Fellow do Computer History Museum em 2017, Intrepid Lifetime Achievement em 2019, National Aviation Hall of Fame em 2022.

A filha resumiu o salto numa frase: “Ela definitivamente passou de ninguém saber quem ela era para, de repente, todo mundo saber, especialmente na área dela” (“She definitely went from nobody knowing who she was to suddenly everyone knowing who she was, especially in her field”, ao WBUR). O professor Olivier de Weck, do MIT, foi mais direto: dizer que ela foi pioneira, ou que estava à frente do seu tempo, “seria um eufemismo dramático” (AP).

Hamilton deixa a filha Lauren, um genro, dois netos, quatro bisnetos e três irmãos. O MIT informou que o memorial está previsto para a primavera, em Cambridge.

O fio para puxar depois

Ela disse uma vez: “Não havia segunda chance. A gente sabia disso” (“There was no second chance. We knew that”, MIT News). O software da Apollo foi escrito sob uma restrição que a gente não tem: nada de hotfix, nada de deploy na terça seguinte.

A pergunta que fica para quem monta fluxos com IA hoje é o contrário disso. Como a correção é baratíssima, quase ninguém projeta para a falha. Se você pudesse rodar com seu setup atual o teste que ela fez, dar o teclado para uma criança de 4 anos por dez minutos, o que quebraria primeiro?

Me conta na @odanigeek no X ou no @odanigeek no Threads. Quero o caso específico em vez da teoria.

(Nota fora do texto: não havia nenhum travessão, meia-risca ou hífen espaçado funcionando como pontuação no corpo da peça, então nada precisou ser reescrito. A única meia-risca é o intervalo de datas no título, que as instruções mandam preservar.)