Filosofia de engenharia: Margaret Hamilton

Pontos principais

• Ela cunhou o termo “engenharia de software” para conquistar a legitimidade da disciplina. Enquanto liderava o esforço de software de voo da Apollo no MIT Instrumentation Laboratory, Margaret Hamilton começou a chamar o trabalho de “engenharia de software” — deliberadamente, para defender que escrever o código que levou pessoas à Lua merecia o mesmo rigor e respeito que a engenharia de hardware e de sistemas, numa época em que o software era tratado como algo secundário.¹²
• Seu software salvou o pouso da Apollo 11 quando o computador de orientação disparou os alarmes 1202 e 1201. Durante a descida final, uma chave do radar de encontro mal configurada alimentou o Apollo Guidance Computer com trabalho espúrio que ele nunca deveria ter recebido, e o executivo ficou sem memória para agendá-lo — os famosos alarmes 1202 (“no core sets”) e 1201 (“no VAC areas”). Como a equipe de Hamilton havia construído o software com agendamento por prioridade e proteção de reinício, o computador descartou as tarefas de radar de baixa prioridade, manteve em execução a orientação crítica para o pouso e o pouso foi bem-sucedido.³⁴⁵
• Seu compromisso definidor é o design defensivo: projetar para o caso de falha, porque não existe segunda chance. “Não havia segunda chance. Sabíamos disso”, disse ela sobre a Apollo.² Detecção de erros, recuperação, agendamento assíncrono por prioridade e telas com o ser humano no circuito não eram recursos acoplados depois que o caminho feliz funcionava — eram o centro do design, a razão pela qual o software se degradava graciosamente em vez de travar.⁶
• Ela embutiu a correção desde o início — “Development Before the Fact”. Após a Apollo, fundou a Higher Order Software (1976) e a Hamilton Technologies (1986), desenvolvendo a Universal Systems Language (USL) e uma metodologia para projetar sistemas de modo que classes inteiras de erro fossem impossíveis por construção, em vez de capturadas por testes. Recebeu o NASA Exceptional Space Act Award (2003) e a Medalha Presidencial da Liberdade (2016).¹⁶

O princípio

“Não havia segunda chance. Sabíamos disso. Levávamos nosso trabalho a sério, muitos de nós começando essa jornada ainda na casa dos 20 anos.” — Margaret Hamilton, sobre o software de voo da Apollo²

A maior parte da engenharia otimiza para o caso em que tudo funciona. Você constrói o caminho feliz, trata alguns erros que consegue imaginar e entrega — e quando algo quebra em produção, você corrige e reimplanta. Esse ciclo é o conforto dentro do qual quase todo software vive: a falha é recuperável porque sempre há uma próxima chance. O trabalho de Hamilton partia da premissa oposta. O software que ela liderava ia levar três pessoas a um quarto de milhão de quilômetros da Terra e pousar duas delas na Lua, e não havia patch, nem reimplantação, nem próxima chance. Tinha que funcionar de primeira, sob condições que ninguém conseguia ensaiar por completo, num computador com menos memória que um cartão de felicitações que toca uma melodia.² Quando o custo de um único erro não capturado é a tripulação, “projetar para o caso de falha” deixa de ser um bom conselho e passa a ser o trabalho inteiro.

O princípio que daí decorre é o design defensivo como o centro do projeto, não como faxina. Se o software precisa sobreviver ao inesperado, então detectar erros, recuperar-se deles e degradar graciosamente não podem ser recursos que você adiciona depois que o caminho funcional está pronto — eles têm que ser o esqueleto no qual o caminho funcional se sustenta. A equipe de Hamilton construiu o software da Apollo de modo que o computador pudesse perceber que estava sendo solicitado a fazer mais do que conseguia, descartar o trabalho que não importava, reiniciar de forma limpa para um estado reconhecidamente bom e continuar fazendo a única coisa que mataria a tripulação se parasse. O sistema não foi construído para evitar toda falha — numa máquina tão pequena, contra uma missão tão implacável, isso é impossível. Foi construído para que, quando a falha chegasse, ela fosse sobrevivível.³⁶

Há uma segunda metade do princípio, e é ela que torna a primeira metade real: embutir a correção desde o início, em vez de extrair os bugs por teste no final. Detectar e recuperar-se de um erro em tempo de execução é a última linha de defesa; a disciplina mais profunda é projetar o sistema de modo que categorias inteiras de erro não possam ocorrer em primeiro lugar. Hamilton passou a segunda metade da carreira formalizando exatamente isso — uma metodologia que ela chamou de “Development Before the Fact” e uma linguagem construída para tornar erros de interface estruturalmente impossíveis.⁶ As duas metades são uma só ideia vista de duas distâncias: quando não há segunda chance, você se defende em tempo de execução e torna a falha irrepresentável em tempo de projeto, porque o único erro em que você pode confiar plenamente é aquele que o sistema nunca foi capaz de cometer.

Contexto

Margaret Hamilton nasceu Margaret Heafield em 17 de agosto de 1936, em Paoli, Indiana.¹ Estudou matemática no Earlham College, formando-se em 1958 com habilitação secundária em filosofia — uma combinação que aparece mais tarde na forma como ela pensava sobre sistemas, tanto quanto sobre código.¹ Ela não chegou à Apollo por um pipeline de ciência da computação, porque no fim dos anos 1950 isso não existia; chegou pela matemática e pelo próprio trabalho.

Sua primeira programação foi do mundo real e de alto risco desde o começo. Em 1959 começou a trabalhar no departamento de meteorologia do MIT com Edward Lorenz — o fundador da teoria do caos — escrevendo software de previsão do tempo nos computadores LGP-30 e PDP-1.¹ De aproximadamente 1961 a 1963 trabalhou no projeto SAGE no MIT Lincoln Laboratory, escrevendo software para o computador AN/FSQ-7 que a Força Aérea dos EUA usava para detectar aeronaves que se aproximavam.¹ O SAGE foi um dos primeiros grandes sistemas de software em tempo real e sensíveis a falhas já construídos, e a reputação que ela conquistou ali — por assumir o código mais difícil e mais propenso a falhas — é o que a levou à Apollo.

Em 1965 ela ingressou no MIT Instrumentation Laboratory (mais tarde Draper Lab), que detinha o contrato para construir o software de voo embarcado do programa Apollo da NASA. Ela ascendeu a dirigir a Divisão de Engenharia de Software, liderando a equipe responsável pelo software de voo embarcado que rodava no Apollo Guidance Computer tanto no módulo de comando quanto no módulo lunar.¹ Foi aqui, no meio desse trabalho, que ela começou a usar o termo “engenharia de software” — não como um chavão, mas como um argumento. Como ela mesma disse, usava o termo “para distingui-la do hardware e de outros tipos de engenharia, mas tratar cada tipo de engenharia como parte do processo geral de engenharia de sistemas.”¹ O software, ela insistia, era uma disciplina que merecia um nome e o rigor que vinha com ele. Após a Apollo, fundou a Higher Order Software em 1976 e a Hamilton Technologies em 1986, onde desenvolveu a Universal Systems Language e a metodologia “Development Before the Fact”.¹⁶

O trabalho

O alarme 1202 da Apollo 11: agendamento por prioridade e proteção de reinício

Comece por aqui, porque é o princípio transformado em mecanismo sob a pior pressão possível. O Apollo Guidance Computer era uma máquina minúscula — algumas dezenas de kilobytes de memória, sem sistema operacional no sentido moderno — rodando um executivo em tempo real que a equipe de Hamilton projetou. Para rodar uma tarefa, o executivo tinha que encontrar memória livre: um “core set” (um pequeno bloco para o estado da tarefa) e, para tarefas que faziam trabalho de ponto flutuante, uma “VAC area”.⁴ Se uma tarefa fosse agendada e nenhum core set estivesse livre, o executivo desviava para sua rotina de alarme e disparava o alarme 1202; se nenhuma VAC area estivesse livre, disparava o 1201.⁴ Esses não eram códigos de travamento. Eram o executivo anunciando que havia sido solicitado a fazer mais do que tinha capacidade — e então fazendo algo a respeito.

Durante os minutos finais da descida da Apollo 11, foi exatamente isso que aconteceu. A lista de verificação dos astronautas mandou a tripulação deixar a chave do radar de encontro na posição errada, o que fez o radar roubar ciclos do processador e levou o executivo a agendar repetidamente tarefas de processamento de dados que nunca deveriam estar rodando.³⁴ O trabalho espúrio consumiu toda a memória livre, e o alarme 1202 disparou — depois disparou de novo, e o alarme 1201 também, quatro vezes nos segundos que antecederam o pouso. Um computador ingênuo, solicitado a fazer tudo, teria tentado fazer tudo, ficado para trás na única tarefa que importava e travado. O de Hamilton não.

Duas decisões de projeto salvaram o pouso. A primeira foi o agendamento por prioridade: o executivo rodava as tarefas por prioridade e podia descartar o trabalho de prioridade mais baixa, de modo que a orientação crítica para o pouso e a tela da tripulação (DSKY) sempre rodavam, enquanto as tarefas inúteis de radar ficavam sem recursos.³⁵ A segunda foi a proteção de reinício: cada alarme acionava um reinício de software que limpava a fila de tarefas sobrecarregada e reiniciava num estado reconhecidamente bom, retomando “as coisas importantes, como conduzir o motor de descida e rodar a DSKY”, mas não reiniciando as tarefas de radar agendadas por engano.⁴⁵ O computador, na prática, jogava fora o ruído, continuava pilotando a nave e avisava à tripulação que estava cuidando disso — razão pela qual o Controle da Missão pôde dar o “go” para um alarme que, num projeto inferior, teria significado abortar.

Por que isso importa como engenharia: o alarme não era a falha — era o tratamento da falha funcionando conforme o projeto. A equipe havia construído o executivo para esperar sobrecarga, fazer triagem sob ela e recuperar-se dela, e havia testado essa recuperação tão a fundo que os controladores confiaram nela sob a maior pressão a que qualquer software já foi submetido. Essa é a doutrina inteira num só momento: a falha era assumida, o caso de falha era o centro do projeto, e o sistema degradava para “fazer apenas a coisa que mantém a tripulação viva” em vez de desabar. O mesmo instinto vive hoje em toda fila de prioridade que descarta carga, todo supervisor que reinicia um worker travado num estado limpo, todo sistema construído para sobreviver a ser sobrecarregado.

Cunhar “engenharia de software” e a luta pela legitimidade

A história do 1202 é famosa; o nome é, possivelmente, mais consequente. Nos anos 1960, o software era amplamente tratado como o irmão fraco e pouco sério da “engenharia de verdade” — algo que você resolvia depois que o hardware era projetado, não uma disciplina com rigor próprio. Hamilton recusou esse enquadramento. Dentro da Apollo, ela começou deliberadamente a chamar o trabalho de “engenharia de software”, e foi explícita sobre o porquê: para “distingui-la do hardware e de outros tipos de engenharia, mas tratar cada tipo de engenharia como parte do processo geral de engenharia de sistemas.”¹ A questão não era vocabulário. A questão era status. Se o código que voou na missão era engenharia, então merecia a disciplina da engenharia: especificações, revisões, testes, rastreabilidade e a expectativa de ser feito correto, não apenas feito para rodar.

Ela contou que o termo foi recebido com diversão no começo — a ideia de que software pudesse ser “engenharia” pareceu às pessoas um exagero.¹ Mas a legitimidade pela qual ela lutava era estrutural. Você não pode exigir que uma equipe projete para o caso de falha, embuta a recuperação de erros nos ossos de um sistema e trate a correção como inegociável se o trabalho for visto como scripting casual que alguém vai arrumar depois. Nomear a disciplina foi a pré-condição para cobrá-la a um padrão. No fim da década, o termo havia escapado do MIT e se tornado o nome de um campo; hoje “engenharia de software” é tão comum que é invisível, o que é o sinal mais seguro de que o argumento foi vencido.¹²

Design defensivo: o “bug da Lauren” e engenharia contra o ser humano

Se você quer a janela mais clara para entender como Hamilton pensava, é o “bug da Lauren”. Sua filha pequena, Lauren, às vezes ia ao laboratório e brincava de astronauta no simulador do módulo de comando, e um dia o travou — ao selecionar o P01, o programa pré-lançamento, enquanto a nave simulada já estava em pleno voo rumo à Lua.⁷ Carregar a inicialização de pré-lançamento em meio à trajetória apagava os dados de navegação e deixava o computador perdido. O instinto de Hamilton não foi “nenhum astronauta jamais faria isso”. Foi: se o simulador deixou uma criança fazer isso, o software permitiu, e tudo o que o software permite acabará acontecendo. Ela propôs adicionar código de detecção de erros para impedir a seleção do P01 em voo.⁷

Ela foi vetada — disseram que astronautas eram profissionais treinados que jamais cometeriam tal erro — e só lhe permitiram acrescentar uma nota à documentação.⁷ Então, logo na missão seguinte, a Apollo 8, Jim Lovell fez exatamente o que Lauren havia feito, selecionando o P01 em pleno voo e apagando os dados de navegação na primeira viagem da humanidade ao redor da Lua.⁷ Depois disso, a correção entrou. A lição que Hamilton extraiu, e repetiu, é o coração do design defensivo: você não pode decidir que uma falha “não pode acontecer” e projetar como se ela não fosse acontecer. O astronauta, a chave do radar, o operador às 3 da manhã — o sistema tem que ser robusto contra o ser humano no circuito, não protegido da culpa por presumir que o ser humano será perfeito. Suas telas de prioridade encarnavam a mesma ideia pela outra direção: manter o ser humano informado e no controle, para que, quando o computador fizesse triagem sob sobrecarga, a tripulação entendesse o que ele estava fazendo e pudesse decidir.⁶

Higher Order Software, USL e “Development Before the Fact”

A Apollo ensinou a Hamilton de onde vêm os erros, e ela passou o resto da carreira atacando-os na raiz. Estudando os erros da Apollo, ela observou que uma grande parcela deles não vivia dentro de módulos individuais, mas nas interfaces entre eles — os lugares onde uma peça de software entregava dados a outra e as premissas não batiam exatamente. Na Higher Order Software (1976) e depois na Hamilton Technologies (1986), ela construiu um corpo de trabalho voltado a eliminar esses erros por construção, em vez de capturá-los por teste.¹⁶

A metodologia se chama “Development Before the Fact”. O nome é a tese: em vez de construir um sistema e depois caçar defeitos a posteriori, você o define — usando um sistema formal, a Universal Systems Language (USL) — com tamanho rigor que classes inteiras de erro, especialmente erros de interface e de integração, tornam-se estruturalmente impossíveis. O modelo é comprovadamente consistente, e código correto pode ser gerado a partir dele, de modo que o defeito é prevenido em tempo de projeto em vez de descoberto em tempo de execução.⁶ É a mesma convicção do executivo da Apollo, levada um nível mais fundo: a recuperação em tempo de execução é a rede de segurança, mas a verdadeira vitória é um sistema que nunca foi capaz de cometer o erro em primeiro lugar. A maior parte da indústria ainda roda o ciclo oposto — entregar, encontrar bugs, corrigir — que é exatamente o ciclo que Hamilton passou trinta anos argumentando estar de cabeça para baixo quando a correção realmente importa.

O método

Olhe transversalmente o executivo da Apollo, a cunhagem de “engenharia de software”, o bug da Lauren e o Development Before the Fact, e os mesmos compromissos se repetem. O método de Hamilton é menos um slogan do que um conjunto de hábitos permanentes.

Projete primeiro para o caso de falha — não há segunda chance. O executivo da Apollo não era um agendador com tratamento de sobrecarga acoplado; sobreviver à sobrecarga era o projeto, porque um computador travado sobre a Lua matava a tripulação.³⁴ A lição transfere-se para muito além do voo espacial: enumere como o sistema falha antes de escrever o caminho em que ele funciona, e deixe o caminho funcional brotar de uma estrutura que já sobrevive às falhas. É a barreira de evidência aplicada à confiabilidade — “funciona no simulador” não é evidência; “descarta carga e continua voando quando o radar o inunda” é — o mesmo padrão de degradação graciosa que Werner Vogels tornou a premissa fundadora da nuvem décadas depois.

Presuma que o ser humano fará o impossível. O bug da Lauren é a regra em miniatura: se o sistema permite uma ação perigosa, alguém — uma criança, um astronauta, um operador cansado — acabará por tomá-la, então “ninguém jamais faria isso” não é uma defesa.⁷ O hábito permanente é proteger o limite contra a entrada que lhe garantiram que jamais chegaria, porque as falhas que mais machucam são aquelas que você decidiu de antemão que não poderiam acontecer. Esse é o mesmo instinto de robustez-contra-o-adversário que Radia Perlman embutiu no roteamento que permanece correto mesmo quando os nós mentem.

Faça triagem sob carga — descarte o sem importância, proteja o crítico. Quando o executivo ficava sem memória, ele não tentava atender a toda requisição; rodava as tarefas de prioridade mais alta e deixava o resto sem recursos, depois reiniciava limpo.³⁵ A disciplina é decidir de antemão qual é a única coisa que jamais pode parar, e construir o sistema de modo que, sob pressão, ele sacrifique todo o resto para manter aquela única coisa rodando. Um sistema sem prioridade é um sistema que falha no pior momento porque tratou a tela da tripulação e a tarefa inútil de radar como iguais.

Embuta a correção, não a teste por dentro. O Development Before the Fact é a recusa do ciclo entregar-depois-depurar: defina o sistema de modo que o erro não possa ser expresso, em vez de construí-lo e caçar o erro depois.⁶ A lição é que o defeito mais barato e mais confiável é aquele que o projeto tornou impossível — a mesma convicção que Barbara Liskov transformou em disciplina de tipos e abstração, e que Leslie Lamport transformou em especificar a correção com precisão antes de escrever o código. É a qualidade é a única variável transformada em fluxo de trabalho: a correção não é uma fase no fim, é o formato da coisa desde o início.

Nomeie a disciplina para poder cobrá-la a um padrão. Chamar o trabalho de “engenharia de software” foi o ato que licenciou todo o resto — especificações, revisões, a expectativa de rigor.¹ O hábito permanente é insistir que o trabalho tem um nome e um padrão, porque você não pode exigir ofício de algo que a organização considera descartável. É o espírito do produto minimamente digno: a coisa vale a pena ser feita direito, então você a faz direito, e defende em voz alta que “direito” é a única forma aceitável.

Cadeia de influência

Quem a moldou

A tradição de matemática e tempo real no MIT. Hamilton veio da matemática e do SAGE — um dos primeiros grandes sistemas de software em tempo real e sensíveis a falhas — e da modelagem do clima com Edward Lorenz, o fundador da teoria do caos.¹ Esse alicerce aparece: ela pensava sobre software como um sistema que tinha que permanecer correto sob condições que ninguém conseguia prever por completo, muito antes de chegar à Apollo. (Influência formativa)

A disciplina implacável do próprio voo espacial. A missão Apollo foi a mestra tanto quanto qualquer pessoa. Um domínio em que um único erro custa a tripulação, em que não há patch e não há segunda chance, força uma forma de trabalhar — defender o caso de falha, recuperar-se em tempo de execução, prevenir o erro em tempo de projeto — que o software comum nunca exige.² A restrição moldou a filosofia. (Influência direta)

A cultura de engenharia de sistemas do programa Apollo. Trabalhar dentro de um programa em que seu software tinha que se integrar a hardware, ao controle da missão e ao procedimento humano a empurrou a ver o software como uma disciplina de engenharia entre várias — que é precisamente o enquadramento por trás de sua cunhagem de “engenharia de software” como parte do “processo geral de engenharia de sistemas”.¹ (Influência formativa)

Quem ela moldou

A própria disciplina da engenharia de software. Ao nomear o campo e defender seu rigor de dentro do projeto de software de maior risco de sua era, Hamilton ajudou a transformar a programação de algo secundário numa disciplina de engenharia com especificações, revisões e a expectativa de correção.¹²

Todo sistema em tempo real tolerante a falhas. Agendamento por prioridade, descarte de carga, reinício-para-estado-reconhecidamente-bom e telas com o ser humano no circuito — os padrões que o executivo da Apollo usou para sobreviver ao alarme 1202 — são hoje o vocabulário padrão dos sistemas resilientes, do controle de voo aos supervisores que mantêm serviços web vivos sob sobrecarga.³⁶

Métodos formais, corretos por construção. O Development Before the Fact e a Universal Systems Language fazem parte da linhagem que argumenta que a correção deve ser projetada e demonstrável, não testada a posteriori — um argumento que percorre os métodos formais e o desenvolvimento orientado por modelos até hoje.⁶

O fio condutor

Hamilton é o ponto de origem da linhagem de confiabilidade desta série — o lugar onde “projetar para o caso de falha” deixou de ser uma preferência e se tornou inegociável, porque vidas dependiam disso, décadas antes de o resto do campo alcançá-la. Werner Vogels construiu a nuvem sobre “tudo falha o tempo todo” e projetou para degradação graciosa em escala planetária; Hamilton projetou para degradação graciosa num computador do tamanho de uma maleta, com uma tripulação em cima dele, e provou que a doutrina funciona quando genuinamente não há segunda chance.³ Radia Perlman construiu redes que se curam sozinhas e permanecem corretas mesmo quando os nós mentem; o executivo de Hamilton curava a si mesmo em tempo real sobre a Lua, reiniciando limpo e descartando as mentiras que o radar quebrado lhe alimentava.⁴ E Leslie Lamport tornou a correção algo que você define com precisão e prova antes de construir — que é exatamente o que o Development Before the Fact busca, uma geração antes e mirando o mesmo alvo.⁶ Onde Vogels diz tudo falha, então permaneça disponível através disso e Perlman diz construa para se curar sozinho, Hamilton disse primeiro e mais duro: não há segunda chance, então projete para a falha antes que ela aconteça, recupere-se dela quando acontecer e construa o sistema de modo que os piores erros jamais tenham sido possíveis. (Ponte da série)

O que eu levo disto

A lição que guardo de Hamilton é construir como se não houvesse segunda chance, mesmo quando obviamente há uma. Quase tudo o que eu entrego vive dentro do conforto que ela não tinha: se quebra, eu empurro uma correção. Essa rede de segurança é real, e ela silenciosamente baixa a régua — deixa-me entregar o caminho feliz e dizer a mim mesmo que vou tratar o caso de falha mais tarde, porque o “mais tarde” existe. A Apollo é a réplica. Quando você genuinamente não pode corrigir depois, descobre que “tratar a falha mais tarde” nunca foi engenharia coisa nenhuma; o caso de falha é a engenharia, e o caminho funcional é só o que sobra depois que o sistema já sobrevive a estar quebrado. Então, quando construo algo agora — uma tarefa que pode ser inundada, uma API que pode ser chamada errado, um caminho que pode ser tomado na hora errada — tento perguntar “qual é a chave do radar na posição errada aqui, e isto a descarta e continua voando?” antes de perguntar se o caminho feliz funciona. Um sistema que só sobrevive à entrada correta é um sistema que eu não terminei.

A segunda lição é que o erro mais confiável é aquele que o projeto tornou impossível. O bug da Lauren fica comigo porque Hamilton estava certa e foi vetada por “ninguém jamais faria isso” — e o universo imediatamente fez isso, na missão seguinte. Meu instinto é capturar erros em tempo de execução, envolver a chamada perigosa numa proteção e seguir em frente. O movimento mais profundo de Hamilton, aquele em que ela passou trinta anos, é projetar o sistema de modo que a chamada perigosa não possa ser feita — tornar o estado ruim irrepresentável em vez de meramente detectado. A recuperação em tempo de execução é a rede; embutir a correção é o chão em que você pisa para não precisar da rede. Nem sempre consigo alcançar essa régua, mas ela reenquadrou o objetivo: a pergunta não é apenas “vou capturar isto quando der errado?”, mas “consigo moldar isto de modo que não possa dar errado em primeiro lugar?” — e a segunda pergunta, quando consigo respondê-la, é sempre a melhor.

FAQ

Margaret Hamilton cunhou o termo “engenharia de software”?

Margaret Hamilton é amplamente creditada por cunhar — ou ao menos popularizar — o termo “engenharia de software”, que ela começou a usar enquanto liderava o esforço de software de voo da Apollo no MIT Instrumentation Laboratory nos anos 1960.¹² Ela o usou deliberadamente para defender que escrever software merecia a mesma legitimidade e o mesmo rigor que o hardware e outras disciplinas de engenharia, explicando que queria “distingui-la do hardware e de outros tipos de engenharia, mas tratar cada tipo de engenharia como parte do processo geral de engenharia de sistemas.”¹ Na época, a ideia de que software pudesse ser “engenharia” foi recebida com certa diversão; hoje o termo é tão padrão que é invisível, o que é a medida de quão completamente o argumento foi vencido.¹

O que foram os alarmes 1202 e 1201 durante a Apollo 11?

Foram alarmes de programa disparados pelo executivo do Apollo Guidance Computer durante os minutos finais da descida lunar. Uma chave do radar de encontro mal configurada fez o radar roubar ciclos do processador e levou o executivo a agendar repetidamente tarefas de processamento de dados que não deveriam estar rodando, o que consumiu toda a memória livre.³⁴ Quando nenhum “core set” de memória estava disponível, o executivo disparava o alarme 1202; quando nenhuma “VAC area” estava disponível, disparava o 1201.⁴ Os alarmes não eram travamentos — eram o executivo relatando que havia sido solicitado a fazer mais do que conseguia e então fazendo triagem. Como o software usava agendamento por prioridade e proteção de reinício, ele descartou as tarefas espúrias de radar, reiniciou num estado reconhecidamente bom, manteve em execução a orientação crítica para o pouso e a tela da tripulação, e o pouso foi bem-sucedido.³⁵

O que Margaret Hamilton fez pelo programa Apollo?

Hamilton ingressou no MIT Instrumentation Laboratory em 1965 e ascendeu a dirigir a Divisão de Engenharia de Software responsável pelo software de voo embarcado que rodava no Apollo Guidance Computer tanto no módulo de comando quanto no módulo lunar.¹ Sua equipe projetou o executivo em tempo real com agendamento assíncrono por prioridade, proteção de reinício, detecção e recuperação de erros e telas de prioridade que mantinham os astronautas informados e no controle — a arquitetura que permitiu ao computador da Apollo 11 sobreviver ao alarme 1202 e completar o pouso.³⁶ Sua citação na Medalha Presidencial da Liberdade a credita por contribuir com “conceitos de software assíncrono, agendamento por prioridade e telas de prioridade, e capacidade de decisão com o ser humano no circuito, que estabeleceram a base para o design e a engenharia de software modernos e ultraconfiáveis.”⁶

O que é “Development Before the Fact”?

“Development Before the Fact” é a metodologia de sistemas que Hamilton desenvolveu na Higher Order Software e na Hamilton Technologies após a Apollo, construída em torno de sua Universal Systems Language (USL).¹⁶ Sua tese é que, em vez de construir um sistema e depois caçar defeitos “a posteriori” por meio de testes, você define o sistema com tamanho rigor e formalidade que classes inteiras de erro — especialmente os erros de interface e de integração que ela constatou dominarem os defeitos da Apollo — tornam-se estruturalmente impossíveis por construção.⁶ O modelo é comprovadamente consistente e código correto pode ser gerado a partir dele, de modo que o defeito é prevenido em tempo de projeto em vez de descoberto em tempo de execução. É a expressão em métodos formais de sua convicção da Apollo: o erro mais confiável é aquele que o sistema nunca foi capaz de cometer.

Fontes