O Imperativo da Velocidade: A Lei de Boyd e o Ciclo OODA no Software

Se a base pra gente ter estabilidade no software é a filosofia da "tecnologia tediosa", o motor que faz a gente correr de verdade é a "Lei da Iteração de Boyd". Essa lei, que veio lá da análise de combate aéreo militar, mostra que a velocidade com que a gente aprende é muito mais importante do que a qualidade de uma decisão isolada. Quando a gente junta a segurança da tecnologia tediosa com a agilidade da Lei de Boyd, a gente cria uma força absurda. O resultado? Um desenvolvimento que é rápido, mas que não quebra no meio do caminho. Como a gente consegue equilibrar essas duas coisas?

O Ciclo OODA: Vantagem do Ritmo

A lei que o Coronel John Boyd criou surgiu depois que ele analisou as lutas no céu durante a Guerra da Coreia. Ele percebeu um paradoxo bem curioso: o caça americano F-86 era tecnicamente pior que o MiG-15 soviético em quase tudo, como na velocidade de subida ou nas curvas fechadas. Mesmo assim, os pilotos do F-86 venciam nove de cada dez combates.

A conclusão do Boyd foi que o segredo da vitória não estava em ser o melhor em cada passo, mas em conseguir girar o ciclo todo mais rápido que o adversário. Ele chamou isso de ciclo OODA: Observar, Orientar, Decidir e Agir. O piloto que completava esse ciclo com mais agilidade conseguia bagunçar a cabeça do oponente, criando confusão e garantindo a vantagem.

E sabe por que o F-86 conseguia ser mais rápido nessas iterações? O motivo era bem simples: os controles dele eram hidráulicos, enquanto os do MiG-15 eram manuais e exigiam muita força física. A cada manobra, o piloto do MiG ficava um pouco mais cansado, e o ciclo dele ia ficando mais lento. No fim de um combate, esse cansaço acumulado deixava o piloto do F-86 ditar o ritmo de tudo. Pra gente que desenvolve software, essa analogia é perfeita: qualquer atrito, seja ele mental ou de processo, é um freio na nossa velocidade. Faz sentido?

A Lei de Boyd no Desenvolvimento de Software

No nosso dia a dia, ser rápido pra iterar é muito mais valioso do que tentar fazer cada iteração ser perfeita. Ter a chance de testar uma ideia, ouvir o que o usuário diz, aprender e ajustar logo o rumo vale muito mais do que gastar meses buscando a solução ideal logo de cara. Conforme demonstrado por Jeff Atwood, o ciclo OODA se aplica perfeitamente às práticas modernas que a gente usa pra acelerar o feedback:

• Testes Unitários Rápidos: Eles precisam rodar em segundos. Se o teste demora muito, a gente acaba rodando menos vezes, e aí o feedback sobre o código demora a chegar.
• Testes de Usabilidade Ágeis: Fazer pequenas mudanças e testar logo com quem usa o sistema ajuda a gente a ver o que não funciona antes de investir tempo demais no caminho errado.
• Metodologias Ágeis: A ideia de ter sprints curtas garante que a gente entregue valor sempre e consiga se reorientar com base no que recebeu de retorno.
• Falhar Cedo, Falhar Frequentemente: O objetivo de testar não é provar que tudo tá certo, mas achar o erro o quanto antes. Afinal, é muito mais barato corrigir algo logo no começo, né?

O princípio aqui é sempre o mesmo: encurtar o ciclo OODA. A meta é conseguir fazer mais iterações no mesmo espaço de tempo, acelerando o aprendizado de todo o time.

Estabilidade e Velocidade: Uma Relação Simbiótica

Escolher tecnologia tediosa e seguir a lei da iteração podem parecer coisas diferentes, mas na verdade elas andam de mãos dadas. A estabilidade de uma tecnologia que a gente já conhece é o que permite acelerar o ciclo OODA do time, porque tira os atritos do caminho.

Lembra do F-86? A vantagem dele não veio de uma tecnologia de outro planeta, mas de algo que reduzia o cansaço do piloto. No software, usar ferramentas novas e instáveis cria atrito e cansa a mente. A gente gasta uma energia enorme tentando entender um stack desconhecido. Quando a gente admite que não conhece algo e prefere usar o que já domina - o que chamamos de "Ignorância Produtiva" -, a gente tira esse peso e foca em resolver o problema real do cliente.

Em um stack que a gente não conhece, cada passo do ciclo OODA sofre:

1. Observar: Fica difícil achar a causa de um bug ou saber o que monitorar.
2. Orientar: É um desafio entender o contexto de um sistema complicado e novo.
3. Decidir: Planejar um ajuste vira um risco, e a incerteza pode deixar a gente paralisado.
4. Agir: A implementação fica lenta e cheia de erros novos.

Agora, quando o stack é "tedioso" e a gente domina tudo, o atrito some. A gente sabe onde o bug costuma se esconder, entende como as peças se encaixam, prevê o impacto das mudanças e corrige tudo com segurança e rapidez.

A tecnologia tediosa funciona como os controles hidráulicos do F-86. Ela libera o time pra focar no trabalho que importa em vez de ficar brigando com as próprias ferramentas. Estabilidade não é o oposto de velocidade; é o chão firme onde a velocidade de verdade é construída.

No próximo artigo, a gente vai ver como colocar esses ciclos OODA rápidos pra funcionar na prática, acelerando as entregas sem perder a mão na estabilidade do sistema.