Todo mundo que trabalha com tecnologia já esbarrou, em algum momento, naquela lógica do “faz agora e depois a gente acerta”. Em alguns ambientes, isso deixa de ser exceção e vira cultura. É aí que entra o Go Horse: uma forma de trabalhar baseada em improviso, pressa e atalhos que, muitas vezes, resolve o problema de hoje criando os de amanhã.
Enquanto metodologias como Scrum e XP tentam trazer organização, previsibilidade e colaboração para o desenvolvimento, o XGH segue por outro caminho: valoriza a velocidade acima da consistência, trata o caos como rotina e transforma gambiarra em processo.
Se você nunca tinha ouvido falar nisso, relaxe. As regras abaixo servem justamente para mostrar, com humor, o que acontece quando o improviso assume o controle.
XGH Manifesto x Agile Manifesto
O eXtreme Go Horse Manifesto pode ser entendido como uma resposta satírica ao Agile Manifesto.
Enquanto o ágil valoriza entrega contínua, adaptação e colaboração, o XGH faz o oposto: prioriza o atalho, ignora o planejamento excessivo e confia que tudo se resolve no caminho.
Em outras palavras: onde o ágil busca clareza, o XGH aceita a confusão. Onde o ágil organiza, o XGH improvisa. Onde o ágil revisa, o XGH entrega.
Os 22 axiomas do XGH
1. Pensou demais, já não é XGH.
No XGH, a reflexão profunda perde espaço para a execução imediata. A regra é simples: faça a primeira coisa que vier à cabeça e siga em frente.
2. Existem três formas de resolver um problema: a correta, a errada e a XGH.
A versão XGH é como a errada, só que mais rápida.
3. Quanto mais XGH você faz, mais vai precisar fazer.
Cada problema resolvido por improviso tende a gerar outros novos. E todos eles acabam sendo tratados do mesmo jeito.
4. XGH é totalmente reativo.
Se o erro ainda não apareceu, ele oficialmente não existe.
5. XGH vale tudo, desde que funcione.
Se resolveu, compilou e ninguém reclamou ainda, já pode seguir adiante.
6. Faça commit antes de qualquer update.
Assim, se algo der errado, pelo menos a sua parte continua “certa”.
7. XGH não trabalha com prazo — trabalha com esperança.
Os prazos do cliente são vistos como detalhes flexíveis. Sempre parece possível entregar tudo, até deixar de ser.
8. Quando o sistema começar a afundar, esteja pronto para sair de cena.
Com o tempo, o projeto vira um monstro. Quando a situação explodir, o ideal é estar com o currículo em dia — ou já ter alguém para culpar.
9. XGH não respeita padrões.
Se o código resolve o problema, ele já cumpriu seu papel. O resto é detalhe.
10. Não existe refatoração; existe retrabalho.
Se algo der errado, a solução é fazer outro XGH rápido e seguir.
11. XGH é anárquico.
Não há dono claro, não há centralização real e cada pessoa faz o que acha melhor no momento em que o problema aparece.
12. Promessas de melhoria aliviam a consciência.
Deixar um TODO no código ajuda a dar aquela sensação de que o problema será resolvido no futuro — mesmo que isso nunca aconteça.
13. Qualidade é relativa; velocidade, não.
No XGH, o que importa é entregar rápido. Qualidade entra na categoria “se sobrar tempo”.
14. XGH é atemporal.
Enquanto outras metodologias mudam de nome, formato e tendência, o XGH continua vivo porque sempre haverá alguém disposto a improvisar.
15. XGH nem sempre parece POG, mas costuma andar perto.
Nem toda gambiarra é idêntica, mas o espírito geralmente é o mesmo.
16. Não tente remar contra a maré.
Se o time inteiro trabalha no improviso, insistir em ordem e organização pode ser uma batalha solitária.
17. Ordem demais pode ser perigosa para o XGH.
Quando o caos começa a ser organizado, o modelo perde a sua “eficiência”.
18. O XGH é seu aliado — até o dia em que você o abandona.
Se você constrói tudo em cima dele e depois tenta migrar para algo mais sério, a transição pode ser dolorosa.
19. Se está funcionando, não mexa.
Questionar algo que “já está em produção” costuma ser visto como perda de tempo, mesmo quando o código está por um fio.
20. Testes são para os fracos.
Se o código compila, muita gente já considera suficiente.
21. Conviva com a sensação de fracasso iminente.
No XGH, sucesso e desastre andam sempre lado a lado. Um projeto pode até parecer que vai dar certo — até não parecer mais.
22. O problema só é seu quando seu nome está na classe.
Se você não escreveu aquilo, é melhor não mexer. Se o autor sumir, faltar ou sair de férias, aí sim o barco afunda de vez.
Por que usar XGH?
Depois de ler todos os axiomas, a pergunta é inevitável: “Mas por que alguém usaria isso?”
A resposta, claro, é irônica. O XGH existe justamente para satirizar ambientes em que o improviso vira regra e a pressão por entrega fala mais alto do que qualquer boa prática.
Dá para crescer na carreira com Go Horse?
Na lógica do XGH, sim. Em ambientes que já operam nesse modelo, quem sabe improvisar, contornar obstáculos e “fazer acontecer” costuma ser visto como alguém eficiente.
Qual é a metodologia mais eficiente: Go Horse ou PMBOK?
Na caricatura do XGH, o Go Horse vence porque não perde tempo com planejamento, escopo, governança ou previsibilidade. A ideia é simples: se entregar, o projeto foi um sucesso — independentemente de como chegou lá.
Existe certificação de Go Horse?
Hein? Ah sim, temos: https://afonso.ia.br/gohorsecertification
E código de ética?
O XGH também tem o seu, só que em versão bem mais… flexível.
Como descobrir se a empresa usa Go Horse?
Se você não sabe qual metodologia é usada, provavelmente já sabe a resposta.
Fechamento
O XGH é uma paródia perfeita de certos ambientes de desenvolvimento: pressa constante, pouca previsibilidade, excesso de improviso e uma enorme confiança de que “depois a gente arruma”.
A força desse conceito está justamente em expor, com humor, um problema real: quando o processo some, a gambiarra deixa de ser exceção e passa a ser cultura.
No fim, o XGH nos faz rir porque é exagerado — mas também porque, em algum nível, lembra situações que muita gente da área já viveu.
