Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

Anúncios

Cargo cult, eXtreme go horse e afins

Depois de alguns anos escrevendo código, e também, observando códigos de outras pessoas, meus códigos antigos e código legado percebi alguns comportamentos e padrões entre o aptidão e/ou tempo de experiência X design do código das pessoas.

Investigando esses padrões, consegui entender melhor os “porquês” da incidência, em projetos grandes e bem financiados, de fenômenos como Cargo cult, eXtreme go horse, programação orientada a gambiarra e afins.

Contextualizando – Cargo Cult, descrito por Steven C. McConnell no livro Code Complete, é o fenômeno cultural observado em tribos indígenas/aborígenes, durante a segunda guerra mundial, que envolviam impactos entre duas civilizações, sendo uma moderna em aspectos tecnológicos e outra primitiva. Durante a guerra, soldados americanos necessitavam pousar em ilhas desertas para recarregar combustíveis ou armar mísseis, entretanto muitas dessas ilhas visitadas eram habitadas por esses povos. Ao ocorrer o choque das civilizações, os primitivos imaginavam que os soldados, com todo seu aparato, fossem deuses. Depois da partida da civilização moderna, os indígenas costumavam fazer rituais em determinados períodos do ano com o intuito de invocar os supostos deuses soldados, mudando assim o comportamento cultural/religioso do local.

Ao trazemos esse conceito para computação temos situações clássicas que vivemos no nosso dia a dia, talvez a mais popular seja : Ao perguntar a um desenvolvedor/gerente/engenheiro: – Para que serve esse pedaço de código? Ele te responde: – Não sei, mas não mexe aí! Pode parar de funcionar! Em outras palavras o desenvolvedor possui um tipo de ritual para realizar determinadas tarefas, como inserir código legado, bibliotecas, classes que não necessariamente são úteis para a implementação do mesmo, acarretando a incompreensão sobre o sistema de forma geral.

Para falar de eXtreme go horse temos que esquecer de qualquer boa prática, Scrum, Kanbam, Pair Programming ou qualquer coisa que lembre engenharia de software, isto é, se focar em escrever código e vencer o prazo. Infelizmente é uma realidade triste do mercado, que muitas vezes pode indicar falta de comprometimento do time e falta de alinhamento de interesses entre equipe/empresa ou má gestão do líder.

A verdade é que o caminho para esses cenários(caóticos) são convergentes podendo ser resumidos em falta de maturidade da parte do líder ou desenvolvedor, insegurança, pressão, contratos com prazos irreais, falta de comprometimento da equipe, etc. Muitas vezes esses motivos também podem acarretar um efeito dominó, piorando a situação exponencialmente.

Claro, podemos determinar inúmeras hipóteses para a solução do problema de desenvolvimento de software, entretanto, é fato que a solução está bem longe de determinar metologias rígidas ou mudar conceitos das mesmas. Temos que ir além, precisamos mudar conceitos, quebrar paradigmas, criar um time com determinação e com aptidão, mensurar e explorar potenciais, trabalhar com dificuldades, amadurecer a equipe e acima de tudo cair na real.