eXtreme Go Horse (XGH) ou Go Horse Process (GHP)


XGHExtreme Go Horse ou Go Horse Process são metodologias de desenvolvimento de software fictícias, criadas pelos profissionais da área para satirizar a triste realidade encontrada no dia a dia das empresas desenvolvedoras de software.

Já falamos aqui no DT sobre Scrum e XP, que são metodologias de desenvolvimento verdadeiras e que requerem uma certa doutrina para serem implantadas nas empresas, porém, como na prática a teoria é outra, muitas empresas ainda não seguem nenhuma metodologia, fazendo o desenvolvimento e correções de seus software nesta sequência: Altera, Executa, Compila! Então, baseado no dia a dia destas empresas, surgiu a ideia de criar métodos de desenvolvimento satirizando os oficiais.

Seguem os primeiros 10 mandamentos da XGH:

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.

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 malaco).

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).

Em uma rápida pesquisa na internet, você encontrará em diversos sites os demais mandamentos, além de conteúdos diversos sobre o assunto.

Últimos 5 artigos de Fernando Fonte

Sobre Fernando Fonte

De Campinas-SP, bacharel em Ciência da Computação. Atua como Analista Programador em uma empresa de tecnologia. Tem experiência no desenvolvendo de softwares para comunicação e controle de hadware via porta serial e sistemas ERP. Possui conhecimento em sistemas operacionais Windows, programação Delphi e Visual Basic 6 e Banco de Dados SQL Server e MySQL. Atualmente estuda C# e Android. Tem interesse em Jogos, Celulares, Smartphones, Notebooks e tudo que for relacionado a tecnologia. Fundador deste site e editor chefe, convidou amigos para lhe ajudar com este projeto.

Deixe uma resposta