Extreme Go Horse - AguiarDev Talks #53

Extreme Go Horse (XGH) é o apelido dado, entre desenvolvedores, ao "processo" de desenvolvimento de software que consiste em não ter processo nenhum: não pensar, não planejar, só entregar. Neste episódio os hosts leem, um a um, os mandamentos do site oficial da "metodologia" e confrontam cada um deles com casos reais que já viveram — o resultado é rir para não chorar, porque boa parte do público já passou por isso em algum projeto.

O que foi discutido

• O primeiro mandamento do XGH ("pensou? não é Extreme Go Horse") — e como, na prática, ele nasce da pressão do gerente por entrega imediata
• A comparação entre XGH e metodologias ágeis — por que o Go Horse é visto como o "inimigo" do Scrum, mas na visão dos hosts só ganhou nome depois que o ágil apareceu
• O terceiro mandamento, sobre cada problema resolvido no Go Horse gerar sete novos — e o ciclo de retrabalho que isso cria
• Bugs que ninguém corrige porque "ainda não incomodou ninguém", até estourarem na mão do cliente
• Código commitado sem sequer compilar, e o hábito de comitar antes de um update para garantir que "a culpa não seja sua"
• Um caso real de consultoria em que um gerente foi demitido por não bater prazos ágeis, e o substituto "resolveu" tudo aplicando Go Horse puro — cortando reuniões e cerimônias — entregando no prazo, mas fora do escopo real do cliente
• Ferramentas modernas (CI, build automatizado, entrega contínua) como antídotos práticos contra o Go Horse, ao forçar o desenvolvedor a pelo menos compilar e testar antes de liberar algo
• A defesa de que o Go Horse, usado como exceção consciente sob pressão real — nunca como regra —, pode ser um mal necessário em alguns cenários de negócio

Principais pontos

Pensar demora, entregar não pode esperar

O primeiro mandamento do Go Horse parte de uma lógica perversa: pensar toma tempo, então a solução é não pensar — fazer a primeira coisa que vier à cabeça e seguir em frente. Os hosts reconhecem que, na visão de quem cobra prazo, esse "raciocínio" chega a soar verdadeiro: a pressão da entrega empurra para o caminho mais rápido, não o mais correto. A analogia usada no programa compara isso a um cozinheiro que promete um prato mais rápido se não lavar os ingredientes — tecnicamente mais veloz, mas ninguém toparia comer.

"Existem três formas de se resolver um problema: a correta, a errada e a extreme Go Horse, que é igual à errada, só que é mais rápido." por Tiago Aguiar

Bugs escondidos até explodirem

Um padrão recorrente discutido no episódio é o bug conhecido e ignorado deliberadamente: alguém encontra o problema, ninguém percebeu em produção, então ele vai para o backlog e fica lá, sem prioridade, até um cliente reclamar. A postura de "funciona para o que interessa agora" adia o custo real do defeito em vez de eliminá-lo, e o problema geralmente volta maior — e mais caro de corrigir — mais adiante.

"Você acha o bug lá e ninguém tem que corrigir. Deixa explodir, um dia algum cliente vai reclamar depois." por Rafael Peixoto

Compilar é o mínimo, e mesmo assim falha

Um dos momentos mais categóricos da conversa é sobre código commitado sem sequer compilar — e pior, sem que ninguém perceba até a pipeline quebrar. Os hosts relatam ter revisado pull requests inteiros, gasto tempo analisando a lógica, para descobrir depois que a pipeline nem chegou a rodar porque o código não compilava. A frequência descrita passa de "aconteceu uma vez, sob correria" para "acontece três vezes por semana" — e aí deixa de ser deslize e vira hábito.

"Compilar é o mínimo do mínimo. Chegou na pipe, quebrou algum teste, de repente você não viu, tudo bem. Mas não compilar é doido, mano." por Rafael Peixoto

O herói que entregou no prazo — e o projeto que saiu do escopo

O episódio traz um caso real de consultoria: um gerente foi dispensado por não bater as entregas de sprint, e o substituto resolveu tudo cortando cerimônias, reuniões com o cliente e boa parte do planejamento, aplicando Go Horse sem nomear a prática. O projeto foi entregue no prazo — mas fora do escopo real que o cliente precisava, porque ele deixou de acompanhar o processo como deveria. O "herói" saiu bem na fita; quem herdou a manutenção herdou também a dívida.

"Entreguei um projeto, só que o que acontece? O projeto estava totalmente fora do escopo do cliente." por Rafael Peixoto

Go Horse como exceção consciente, nunca como regra

Apesar do tom de piada, a conversa chega a um ponto de equilíbrio: em situações extremas — prazo impossível, pressão real, recursos insuficientes — recorrer ao Go Horse pode ser inevitável, e às vezes necessário para salvar um contrato ou uma empresa em dificuldade. A diferença entre isso e o antipadrão puro está em tratar a decisão como exceção combinada e consciente, com plano para resolver a dívida depois, e não como cultura permanente de time.

"Em situações extremas, tipo assim, pode usar. Mas tem que ser uma escolha consciente, e saber que isso é exceção." por Tiago Aguiar

Frase de destaque

"Quanto mais Xtreme Go Horse você faz, mais precisará fazer. Para cada problema resolvido usando essa metodologia, mais sete são criados." por Tiago Aguiar

Lições do episódio

1. Pular etapas de pensamento e planejamento não elimina o trabalho — só o adia, geralmente com juros.
2. Um bug ignorado não desaparece: ele só muda de mão, normalmente para quem está mais perto do cliente.
3. Compilar e rodar testes antes de subir código é o piso mínimo de qualquer processo, não um luxo.
4. Entregar no prazo não é o mesmo que entregar o que o cliente realmente precisava — escopo importa tanto quanto velocidade.
5. Ferramentas como CI e entrega contínua funcionam como barreira prática contra atalhos perigosos, porque forçam feedback mais cedo.
6. Se o Go Horse for necessário, que seja exceção combinada e temporária — nunca a cultura padrão do time.