Bem vindo à indústria de software mais paranoica do planeta

Quando você escreve um endpoint em Node.js às 17h58 de sexta-feira, dá git push e vai pro bar o pior cenário possível é um alerta no zap às 3h da manhã. Você rola o log, manda um hotfix e na segunda de manhã ninguém lembra do incidente.

Agora imagina que o seu "endpoint" controla as asas de um avião com 300 pessoas a 11km de altitude. Aqui, o "pior cenário" é uma investigação internacional envolvendo autoridades de três continentes, anos de análise e a leitura detalhada de cada linha de código e documentação que você escreveu.

Esse é o software aeronáutico. E ele é feito por gente que olha para o seu "move fast and break things" exatamente como você olha para quem usa eval() em produção: uma mistura de nojo e curiosidade antropológica.

O deploy que leva anos

No mundo do desenvolvimento "normal", agilidade é a palavra de ordem. Se o CI/CD demora mais de 15 minutos, o time de DevOps já começa a suar frio. No software aeronáutico, o "deploy" é um processo que pode levar anos. Literalmente.

E não é porque os engenheiros são lentos ou usam ferramentas velhas. É porque o ônus da prova é absurdo.

Parece piada, mas é um dia comum na indústria: imagine uma sala com 3 engenheiros seniores, um especialista em segurança de sistemas e um representante da autoridade certificadora. Eles estão na terceira reunião da mês para decidir como tratar a inicialização de uma única variável de estado. Isso não é burocracia. Isso é o que sobra quando um bug mata centenas de pessoas.

A variável precisa começar em zero. Óbvio, certo? Não.

Zero é um valor. Um valor é um comportamento. Um comportamento precisa de um requisito funcional que justifique por que zero é o valor correto. Precisa de um caso de teste que prove que a inicialização foi implementada. Precisa de uma revisão independente que confirme que o teste não é tautologia. E precisa de rastreabilidade: da variável no código, de volta ao requisito, ao teste, à revisão e à configuração exata que gerou o binário. Não como metafora. Como evidência documental que um auditor consegue entender e questionar.

Aquela variável esta dentro de um loop que roda 60 vezes por segundo decidindo o ângulo do profundor. Um valor inicial errado num caso de borda pode virar deflexão inesperada na superfície que controla para aonde o nariz da aeronave aponta. A reunião não é sobre a variável. É sobre fechar a cadeia de rastreabilidade. Se você trocar esse zero por um acabou de invalidar quatrocentas páginas de documentos.

Como chegamos até aqui

Cockpit de avião antes dos anos 70 era analógico. Instrumentos eram literalmente mecânicos: ponteiros, giroscópios, agulhas movidas por sincros e servos. O piloto lia tudo direto da física do mundo. Não tinha software entre ele e o avião.

Os primeiros sistemas digitais a entrarem no cockpit foram coisas isoladas: radar meteorológico, computador de navegação inercial. Sistemas de propósito específico, sem interação real com o resto da aeronave. Software era ainda um inquilino, não o dono da casa.

Aí veio o Airbus A320, em 1988: o primeiro avião comercial com fly-by-wire. Sem cabos do manche para as superficies de controle. Um joystick mandando comandos elétricos para computadores de voo que decidem em tempo real o que mover e quanto. Pela primeira vez, software estava entre o piloto e o controle da aeronave. Não como assistência. Como caminho obrigatório. Foi um terremoto regulatório. E abriu a porteira.

Depois disso veio a avalanche. EFIS substituiu os ponteiros por glass cockpit. FMS começou a planejar a rota inteira. FADEC tomou o controle dos motores. TCAS, TAWS, ACARS, CPDLC, tudo migrou para software. Hoje, um Boeing 787 ou um Airbus A350 é, sem exagero, um sistema distribuído com dezenas de computadores conversando em tempo real por vários barramentos diferentes que por acaso tem asas e voa.

O computador com asas

Durante décadas, cockpit de avião comercial grande tinha três pessoas: comandante, copiloto e engenheiro de voo. O engenheiro de voo não estava ali para fazer charme vintage com painel cheio de botão. Ele monitorava sistemas elétricos, hidráulicos, combustível, pressurização, motores, ar-condicionado, performance, falhas e configuração da aeronave. Era uma pessoa dedicada a gerenciar a complexidade técnica do avião. Depois ele desapareceu. Não porque a complexidade desapareceu. Porque ela foi absorvida por software.

E isso leva a uma pergunta: se o software já substituiu o engenheiro de voo, por que não substituir também os pilotos? A resposta honesta é: porque você não entraria nesse avião. O software já controla muito mais do voo do que o passageiro médio imagina. Tecnicamente a automação já voa o avião sozinha grande parte do tempo. O piloto vive há décadas o que o programador está começando a viver agora com IA: deixou de ser operador direto e virou supervisor de uma automação que faz quase tudo.

Ele programa intenção, monitora modos, acompanha parâmetros, interpreta alertas, valida comportamento e intervém quando algo parece errado. Soa familiar?

E, às vezes, o piloto percebe que a máquina está fazendo algo errado, mas não entende a tempo por quê, ou não tem informação suficiente, ou não consegue recuperar autoridade rápido o bastante. O caso do MCAS no Boeing 737 MAX é uma aula dolorosa disso e vale fazer uma distinção importante: não foi um “bug de software” no sentido vulgar da palavra. Estava na cadeia que justificava aquela linha de código. Lembra da rastreabilidade?

Aquelas linhas apontavam para requisitos de software. Os requisitos de software apontavam para requisitos de sistema. Os requisitos de sistemas apontavam para hipóteses sobre operação, falhas, tripulação e segurança. E algumas dessas hipóteses estavam erradas. É por isso que rastreabilidade não é enfeite.

A responsabilidade do engenheiro

Não, sua API REST de e-commerce não precisa de DO-178C. Aplicar isso onde não faz sentido. Torna o custo da software até 20 vezes maior. A norma existe porque a alternativa é cair do céu e cair do céu é um requisito de negócio que a maioria de nós felizmente não tem.

Mas três perguntas valem qualquer indústria. E são as três perguntas que software aeronáutico responde por design.

1. Por que esse código existe?
   Pega um arquivo aleatório do seu repositório de produção. Vai até uma função qualquer. Pergunta: por que essa função existe? Quem pediu? Que problema ela resolve? Onde está escrito que esse problema precisa ser resolvido?

2. Que evidência mostra que está correto?
   "Tem teste" não é resposta. "Cobertura de 100%" não é resposta. Essas são métricas, não evidências. Evidência é: existe um caso de teste que exercita o comportamento descrito naquele requisito e foi revisado por alguém?

3. Você garante que dependências não introduziram erros?
   Esse é o ponto que mais incomoda. Se o GCC introduz um bug no seu binário (é raro, mas acontece) de controle de voo, a culpa não é do Richard Stallman. É sua, por não ter verificado que o código objeto gerado estava correto. O exemplo é com compilador, mas o princípio vale pra qualquer dependência: você não "usa" uma ferramenta você assume responsabilidade pelo output dela.

Topa o desafio?

Se você gosta da ideia de trabalhar com software onde cada decisão precisa ter motivo, evidência e consequência talvez você goste dessa paranoia.

Se essa indústria te interessou, ela está contratando:

https://embraer.gupy.io/jobs/11109574
https://embraer.gupy.io/jobs/11111449
https://embraer.gupy.io/jobs/11111453