eXtreme Go-Horse Process

XGH - en.txt

eXtreme Go Horse (XGH) Process

Source: http://gohorseprocess.wordpress.com

1. Did you think? then, it's not XGH.
In XGH you don't think, you do the first thing that comes to your mind. There's not a second option as the first one is faster.

2. There are 3 ways of solving a problem: the right way, the wrong and the XGH one, which is exactly like the last one but faster.
XGH is faster than any development process you know (see Axiom 14).

3. You'll always need to do more and more XGH.
For every solved problem using XGH, 7 more are created. And all of them will be solved using XGH. Therefore XGH tends to the infinite.

4. XGH is completely reactive.
Errors arise only when they appear.

5. In XGH anything goes.
It solves the problem? It compiled? You commit and don't think about it anymore.

6. You do commit always before updating.
If things go wrong, your part will always be correct... and your colleagues will be the ones who deal with the issues.

7. XGH don't have deadlines nor milestone.
Deadlines and milestones given to your clients are merely details. You will ALWAYS be able to deploy EVERYTHING on time (even if you have to run a messy script to access to DB).

8. Be ready to jump off when the boat starts sinking. Or else, blame someone or something.
Someday the boat sinks for people that use XGH. As time goes on, the system becomes a bigger monster. Your resume needs to be ready when the doomsday comes, or else blame someone or something else.

9. Be authentic. XGH don't follow standards.
Write code as you may want. If it solves the problem, then "commit" that's it.

10. There's no refactoring, just rework.
If everything goes wrong just apply another XGH to quickly solve the problem. Whenever the problem requires rewriting the whole software it's time for you to jump off the boat (see Axiom 8).

11. XGH is anarchic.
There's no need for a project manager, since it is disponsable. There's no Product Owner, everyone does whatever they want when the problems and requirements appear.

12. Always believe in improvement promises.
Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer. He/She won't feel guilt for the shit he/she did. Sure there won't be no refactoring (see Axiom 10).

13. XGH is absolute.
Milestones and costs are absolute, quality is relative. Never think about quality but instead think about the minimum time required to deploy a solution. I mean, don't think. JUST DO IT!

14. XGH is not a fad.
Scrum, XP? Those are just trends. XGH developers don't follow temporary trends. XGH will always be used by those who despise quality.

15. XGH is not always WOP (Workaround-oriented programming).
Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).

16. Don't try to row against the tide.
If your colleagues use XGH and you are the only sissy who wants to do things the right way then quit it! For any design pattern that you apply correctly, your colleagues will generate 10x more rotten code using XGH.

17. XGH is not dangerous until some order comes up.
This axiom is very complex but it says that a XGH project is always in chaos. Don't try to put order into XGH (see Axiom 16), since it's useless and you'll waste a lot of precious time. 
This will make everything worse even faster. Don't try to manage XGH, since it's self-managed (see Axiom 11) as well as the chaos.

18. XGH is your bro. But it's vengeful.
XGH will always be at your side, as long as you wish. But be awared, do not quit it. If you start something using XGH and then turn to some trendy methodology you will be screwed up.
XGH doesn't allow refactoring (see Axiom 10) and your new sissy system will collapse. In that moment, XGH can save you.

19.  If It Ain't Broke, Don't Fiddle With It.
Never ever change - or even question - a working code. That's a complete waste of time, even more because refactoring doesn't exist (see Axiom 10).
Time is the gear that moves XGH and quality is just a meaningless detail.

20. Tests are for pussies.
If you ever worked with XGH you better must know what you're doing, and if you know what you're doing; why test then? Tests are a waste of time. If it compiles, then it's ok.

21. Be used to the 'living on the edge' feeling.
Failure and sucess are really similar and XGH is not different. People normally think that a project can have greater chances of failing when using XGH. 
However, success is just a point of view. The project failed. Did you learn something with it? Then, for you it was a success!

22. The problem is only yours when you name is on the code docs.
Never touch a class of code which you're not the author. When a team member dies or stays away for too long, everything wil go wrong. In this case, use Axiom 8.

XGH - ES-VE.txt

Fuente: http://gohorseprocess.wordpress.com

1- Pensó, no es XGH. 

En XGH no piensa, haz lo primero que se te venga a la mente. No existe 
segunda opción, a única opción es la más rápida. 

2- Existen 3 formas de resolver un problema: la correcta, la incorrecta y 
la XGH, que es igual a la incorrecta, pero más rápida. 

XGH es más rápido que qualquiera de las metodologia de desarrollo de 
software que usted conoce (Ver Axioma 14). 

3- Mientras más XGH usted haga, necesitará hacer más y más XGH.

Por cada problema resuelto usando XGH, estará creando otros 7 nuevos. Sin
embargo, todos ellos serán resueltos de la forma XGH. XGH tiende al infinito.

4- XGH es totalmente reactivo.

Los errores existen solamente cuando aparecen. 

5- En XGH todo es válido, excepto "dar el chiquito".
Problema resolvido? Compiló? Commit y ya. 

6- Commit siempre antes de update.

Si todo anda mal, su parte estará siempre cierta... y sus compañeros que 
se jodan. 

7- XGH no hay plazo. 

Los plazos pasados a sus cliente son pequeños detalles. SIEMPRE conseguirá
entregar e implementar TODO a tempo (aunque eso implique acceder a la BD via
script todo chapuzado sacado de los cabellos). 

8- Esté preparado para saltar del barco cuando comience a hundirse? 
O échele la culpa a alguien o algo. 

Para quien usa XGH, un dia el barco se hunde y con el pasar del tiempo, 
el sistema se va convirtiendo cada vez más en un monstruo más y más grande. 
El dia que todo se vaya por el caño, es mejor tener listo el curriculum, 
o tener algo/alguien a que/quien echarle culpa. 

9- Sea auténtico, XGH no respeta normas ni estándares. 

Escriba el código de la forma como usted mejor entendió. Si solucionó el problema, 
commit y listo.

10- No existe REFACTORING, solamente REWORK. 

Si las cosas salen mal, haga otro XGH "rapidito" que solucione el problema. El día
que el REWORK (retrabajo) implique reescribir toda la aplicación, salte del barco, con toda
seguridad se va a hundir (Ver Axioma 8).

11- XGH es totalmente anárquico. 

La figura de un gerente de projecto es totalmente desechable. No tiene dueño, 
cada quien hace lo que se le viene en gana cuando los problemas y requisitos 
van surgiendo (Ver Axioma 4).

12- Ilusiónese siempre con promesas de mejorías. 

Colocar TODO (en inglés: PARA HACER) en el código como uma promesa de mejoría ayuda al desarrollador 
XGH a no sentir remordimiento o culpa por las cagada que hizo. Claro que nunca 
habrá REFACTORING (Ver Axioma 10). 

13- XGH es absoluto, no se aferra a cosas relativas. 

Plazo y costo son absolutos, calidad es totalmente relativa. Jamás piense en
calidad, solo en el menor tiempo que la solução será implementada. Mejor dicho, 
no piense, haga!

14- XGH es atemporal. 

Scrum, XP? todo eso es moda. XGH no se apega al "último grito de la moda",
eso es cosa de marica. XGH siempre fue y siempre será usado por aquellos que 
desprecian la calidad. 

15- No siempre XGH es CE (Código Espagueti). 

Muchos CE's exigen un razonamiento muy elevado, XGH no piensa (Ver Axioma 1). 

16- Não intente nadar contra la corriente. 

Caso sus compañeros de trabalho usen XGH para programar y usted es un "sifrino" (Venezuela),
"gomelo" (Colombia), "cheto" (Argentina), "pijo" (España), y por ahí va...  que le gusta 
hacer las cosas bien, olvídelo! Para cada "DESIGN PATTERN" que use correctamente, sus colegas
generarán 10 veces más código puerco usando XGH. 

17- XGH no es peligroso hasta que surge un poco de orden. 

Este axioma es muy complejo, pero sugiere que el proyecto que esté utilizando
XGH está en medio del caos. No trate de poner orden en XGH (Ver Axioma 16), es
inútil y usted puede desperdiciar un tiempo precioso. Esto hará con que el
proyecto se hunda aún más rápido (Ver Axioma 8). Tampoco intente gerenciar el XGH,
él es auto suficiente (Ver Axioma 11), así como lo es el caos. 

18- O XGH es tu "BROTHER", pero tenga en cuenta que es vengativo. 

Hasta que usted quiera, XGH estará sempre de su lado. Pero cuidado, no lo abandone.
Si comienza un sistema utilizando XGH y luego lo abandona para utilizar una metodologia de moda,
usted estará jodido. XGH no permite REFACTORING (ver axioma 10), y su nuevo sistema lleno de
"parafernarias, adornitos y perfumes" entrará en colapso. En ese momento, solamente XGH podrá salvarlo. 

19- Si funciona, no lo toque. 

Nunca altere, y mucho menos cuestione un código funcionando. Eso es pérdida de tiempo, hasta
porque REFACTORING no existe (Ver Axioma 10). Tempo es el engranaje que mueve XGH y la calidad
es un detalle despreciable.

20- Pruebas es para los débiles. 

Si le metió la mano a un sistema XGH, es mejor saber o que está haciendo, y si sabe lo que está
haciendo, para qué va a probar? Pruebas son un desperdicio de tiempo. Si el código compila, es más
que suficiente. 

21- Acostúmbrese al sentimento de fracaso inminente. 

El fracaso y el éxito están siempre de la mano, y en XGH no es diferente. Las personas suelen pensar
que las probabilidades del proyecto fracasar utilizando XGH son siempre mayores a las del tener éxito.
Pero éxito y fracaso son una cuestión de punto de vista. El proyecto se fue por el precipicio pero usted
aprendió algo? Entonces fue un éxito para usted! 

22- El problema solamente es suyo cuando su nombre está en la Documentación de la clase. 

Nunca le meta la mano a una clase cuyo autor no sea usted. En caso de que un miembro del equipo se muera o 
se enferme por mucho tiempo, el barco se va a hundir! En ese caso, use el Axioma 8.

XGH - PT-BR.txt

Fonte: http://gohorseprocess.wordpress.com

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

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.