banaslee · April 14, 2025 05:43 · marciok · Jun 4, 2015 · cigano · Nov 13, 2015
diff --git a/XGH - de-de.txt b/XGH - de-de.txt
 eXtreme Go Horse (XGH) Process

 Quelle: http://gohorseprocess.wordpress.com

 Übersetzung ursprünglich von https://gist.github.com/Neffez/f8d907ba8289f14e23f3855011fa4e2f

 1. Ich denke, also ist es nicht XGH.
 In XGH wird nicht gedacht, es wird das erste gemacht, was in den Sinn kommt. Es gibt auch keine zweite Option, die erste ist schneller.

 2. Es gibt 3 Wege ein Problem zu lösen: den richtigen Weg, den falschen Weg und den XGH Weg, welcher exakt wie der falsche ist, aber schneller.
 XGH ist schneller als jeder Entwicklungsprozess, den Du kennst (siehe Axiom 14).

 3. Du wirst immer mehr und mehr XGH brauchen.
 Für jedes mit XGH behobene Problem entstehen 7 neue. Und alle davon werden mit XGH gelöst. Deshalb tendiert XGH gegen das Unendliche.

 4. XGH ist komplett reaktiv.
 Fehler existieren erst, wenn sie auftreten.

 5. In XGH geht alles.
 Es löst das Problem? Es kompiliert? Du committest und denkst nicht mehr darüber nach.

 6. Du committest immer bevor Du updatest.
 Wenn Dinge schief gehen, wird dein Teil immer korrekt sein... und Deine Kollegen werden diejenigen mit den Problemen sein.

 7. XGH hat keinen Zeitplan.
 Zeitpläne von deinen Kunden spielen keine Rolle. Du wirst IMMER in der Lage sein ALLES rechtzeitig zu implementieren (selbst wenn das bedeutet mit einem verrückten Skript auf die Datenbank zuzugreifen).

 8. Sei bereit vom Schiff zu springen, sobald es anfängt zu sinken. Oder beschuldige jemand anderen.
 Für Menschen, welche XGH verwenden, wird eines Tages das Schiff sinken. Mit der Zeit wird das System in eine immer größere Monstrosität wachsen. Du hast besser deinen Lebenslauf bereit, wenn es so weit ist. Oder Du hast jemand anderen zum Beschuldigen.

 9. Sei ketzerisch. XGH folgt keinen Mustern.
 Schreibe Code wie du willst. Wenn es das Problem löst, committe es und vergiss es.

 10. Es gibt kein Refactoring, nur Rework.
 Wenn die Dinge jemals schief laufen, nutze einfach XGH um die Probleme schnell zu lösen. Sobald die Probleme erfordern die komplette Software neu zu schreiben, wird es Zeit für Dich zu verschwinden, bevor das Ganze unter geht. 

 11. XGH ist anarchisch.
 Ein Projektmanager wird nicht benötigt. Es gibt keinen Owner und jede/r macht was auch immer er/sie will, sobald die Probleme und Anforderungen auftauchen.

 12. Glaube immer an Versprechen besser zu werden.
 TODO-Kommentare im Code als Versprechen, dass der Code später besser gemacht wird, hilft dem/der XGH Entwickler/-in. Er/Sie wird sich nicht schuldig fühlen, was er/sie getan hat. Aber natürlich wird es kein Refactoring geben (siehe Axiom 10).

 13. XGH ist absolut.
 Lieferdaten und Kosten sind absolute Dinge. Qualität ist relativ. Denke niemals über die Qualität, sondern darüber, auf welche Weise eine Lösung mit minimalem Zeitaufwand implementiert werden kann. Denke nicht, tu es!

 14. XGH ist kein Trend.
 Scrum, XP? Das sind nur Trends. XGH Entwickler folgen keinen temporären Trends. XGH wird immer benutzt werden, von allen die Qualität verachten.

 15. XGH ist nicht immer WOP (Workaround-orientierte Programmierung).
 Viele WOPs benötigen schlaues Denken. XGH benötigt kein Denken (siehe Axiom 1).

 16. Versuche nicht gegen den Strom zu schwimmen.
 Wenn deine Kollegen XGH verwenden und du bist die einzige Memme, welche es richtig machen will, dann vergiss es! Für jedes Design Pattern, welches Du korrekt anwendest, werden deine Kollegen mit XGH zehnmal mieseren Code produzieren.

 17. XGH ist niemals gefährlich, solange du keine Ordnung darin siehst.
 Dieses Axiom ist sehr komplex, aber es besagt, dass ein XGH Projekt immer im Chaos endet. Versuche keine Ordnung reinzubringen (siehe Axiom 16). Es ist sinnlos und Zeitverschwendung. Dadurch wird alles nur schneller untergehen. Versuche nicht XGH zu organisieren, es ist eigenständig (siehe Axiom 11) und Chaos.

 18. XGH ist dein Kumpel. Aber es ist rachsüchtig.
 Während du es willst, ist XGH immer an deiner Seite. Aber pass auf, es niemals aufzugeben. Wenn Du etwas mit XGH beginnst und dann mit irgendeiner trendigen Methode weitermachst, bist du geliefert. XGH erlaubt kein Refactoring (siehe Axiom 10) und dein neues Weichei-System wird kollabieren. Wenn das passiert, kann dich nur XGH retten.

 19. Wenn es funktioniert, lass es in Ruhe.
 Ändere niemals - oder denke gar nicht erst daran - funktionierenden Code. Das ist absolute Zeitverschwendung und vor allem existiert kein Refactoring (siehe Axiom 10).
 Zeit ist der Motor hinter XGH und Qualität ist nur ein sinnloses Detail.

 20. Tests sind für Weicheier.
 Wenn Du jemals mit XGH gearbeitet hast, weißt du besser was du tust. Und wenn Du es weißt, warum dann testen? Tests sind Zeitverschwendung. Wenn es kompiliert, ist es gut.

 21. Gewöhne dich an das Gefühl gefählich zu leben.
 Erfolg und Misserfolg sind ziemlich ähnlich und XGH ist nicht anders. Die Leute denken normalerweise, dass ein Projekt eher fehlschlägt, wenn man XGH verwendet. Aber Erfolg ist nur eine Frage des Standpunkts.
 Das Projekt ist fehlgschlagen, aber Du hast dabei was gelernt? Dann war es ein Erfolg für Dich!

 22. Es ist nur dein Problem, wenn dein Name in der Code-Dokumentation steht.
 Fasse niemals eine Klasse an, von welcher du nicht der Author bist. Wenn ein Teammitglied stirbt oder zu lange weg bleibt, wird das Ganze untergehen. Wenn das passiert, nutze Axiom 8.

 ### Gemeinschaftliche Ergänzung

 23. Mehr ist mehr.
 Mit XGH strebst du nach Code-Duplizierung - Code-Qualität ist bedeutungslos und für Codereviews und Refactoring ist keine Zeit. Zeit ist Geld, also Copy+Paste, schnell!
diff --git a/XGH - en.txt b/XGH - en.txt
 eXtreme Go Horse (XGH) Process

 Source: http://gohorseprocess.wordpress.com


 1. I think therefore 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 way and the XGH way which is exactly like the wrong 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 only come to exist 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 commit always before updating.
 If things go wrong your part will always be correct... and your colleagues will be the ones dealing with the problems.

 7. XGH don't have schedules.
 Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the DB through some crazy script).

 8. Be ready to jump off when the boat starts sinking. Or blame someone else.
 For people using XGH someday the boat sinks. As time passes by the system grows into a bigger monster. You better have your resume ready for when the thing comes down. Or have someone else to blame.

 9. Be authentic. XGH don't follow patterns.
 Write code as you may want. If it solves the problem you must commit and forget about it.

 10. There's no refactoring just rework.
 If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem requires rewriting the whole software it's time for you to drop off before the whole thing goes down.

 11. XGH is anarchic.
 There's no need for a project manager. There's no owner and 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.
 Delivery dates and costs are absolute things. Quality is relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually, don't think. Do!

 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 10 times more rotten code using XGH.

 17. XGH is not dangerous until you see some order in it.
 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). It's useless and you'll spend a lot of precious time. This will make things go down even faster. Don't try to manage XGH as it's auto-sufficient (see Axiom 11) as it's also chaos.

 18. XGH is your bro. But it's vengeful.
 While you want it XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up. XGH doesn't allow refactoring (see Axiom 10) and your new sissy system will collapse. When that happens only XGH can save you.

 19. If it's working don't bother.
 Never ever change - or even think of question - a working code. That's a complete waste of time even more because refactoring doesn't exist (see Axiom 10).
 Time is the engine behind XGH and quality is just a meaningless detail.

 20. Tests are for pussies.
 If you ever worked with XGH you better 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 it's good.

 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. But success is just a way of seeing it. 
 The project failed. You learned 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 the thing will go down. When that happens use Axiom 8.

 ### Community addition

 23. More is more.
 With XGH you thrive on code duplication - code quality is meaningless and there's no time for code reviews or refactoring.  Time is of the essence, so copy and paste, quickly!
diff --git a/XGH - es-ve.txt b/XGH - es-ve.txt
 Fuente: http://gohorseprocess.wordpress.com

 Traducción originalmente de https://gist.github.com/upcesar/bfd685f12eb1dfb9eaa7176ab2642f4f

 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.

 ### Adición de la comunidad

 23.	Más es más.
 Con XGH prosperas con la duplicación de código: la calidad del código no tiene sentido y no hay tiempo para revisiones ni refactorización. El tiempo es esencial, ¡así que copia y pega rápido!
diff --git a/XGH - pt-br.txt b/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  . 

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

 ### Contribuição da comunidade

 23. Mais é mais.

 Com o XGH você prospera na duplicação de código - a qualidade do código não tem sentido e não há tempo para revisões de código ou refatoração. O tempo é essencial, então copie e cole, rapidamente!
	eXtreme Go Horse (XGH) Process

	Quelle: http://gohorseprocess.wordpress.com

	Übersetzung ursprünglich von https://gist.github.com/Neffez/f8d907ba8289f14e23f3855011fa4e2f

	1. Ich denke, also ist es nicht XGH.
	In XGH wird nicht gedacht, es wird das erste gemacht, was in den Sinn kommt. Es gibt auch keine zweite Option, die erste ist schneller.

	2. Es gibt 3 Wege ein Problem zu lösen: den richtigen Weg, den falschen Weg und den XGH Weg, welcher exakt wie der falsche ist, aber schneller.
	XGH ist schneller als jeder Entwicklungsprozess, den Du kennst (siehe Axiom 14).

	3. Du wirst immer mehr und mehr XGH brauchen.
	Für jedes mit XGH behobene Problem entstehen 7 neue. Und alle davon werden mit XGH gelöst. Deshalb tendiert XGH gegen das Unendliche.

	4. XGH ist komplett reaktiv.
	Fehler existieren erst, wenn sie auftreten.

	5. In XGH geht alles.
	Es löst das Problem? Es kompiliert? Du committest und denkst nicht mehr darüber nach.

	6. Du committest immer bevor Du updatest.
	Wenn Dinge schief gehen, wird dein Teil immer korrekt sein... und Deine Kollegen werden diejenigen mit den Problemen sein.

	7. XGH hat keinen Zeitplan.
	Zeitpläne von deinen Kunden spielen keine Rolle. Du wirst IMMER in der Lage sein ALLES rechtzeitig zu implementieren (selbst wenn das bedeutet mit einem verrückten Skript auf die Datenbank zuzugreifen).

	8. Sei bereit vom Schiff zu springen, sobald es anfängt zu sinken. Oder beschuldige jemand anderen.
	Für Menschen, welche XGH verwenden, wird eines Tages das Schiff sinken. Mit der Zeit wird das System in eine immer größere Monstrosität wachsen. Du hast besser deinen Lebenslauf bereit, wenn es so weit ist. Oder Du hast jemand anderen zum Beschuldigen.

	9. Sei ketzerisch. XGH folgt keinen Mustern.
	Schreibe Code wie du willst. Wenn es das Problem löst, committe es und vergiss es.

	10. Es gibt kein Refactoring, nur Rework.
	Wenn die Dinge jemals schief laufen, nutze einfach XGH um die Probleme schnell zu lösen. Sobald die Probleme erfordern die komplette Software neu zu schreiben, wird es Zeit für Dich zu verschwinden, bevor das Ganze unter geht.

	11. XGH ist anarchisch.
	Ein Projektmanager wird nicht benötigt. Es gibt keinen Owner und jede/r macht was auch immer er/sie will, sobald die Probleme und Anforderungen auftauchen.

	12. Glaube immer an Versprechen besser zu werden.
	TODO-Kommentare im Code als Versprechen, dass der Code später besser gemacht wird, hilft dem/der XGH Entwickler/-in. Er/Sie wird sich nicht schuldig fühlen, was er/sie getan hat. Aber natürlich wird es kein Refactoring geben (siehe Axiom 10).

	13. XGH ist absolut.
	Lieferdaten und Kosten sind absolute Dinge. Qualität ist relativ. Denke niemals über die Qualität, sondern darüber, auf welche Weise eine Lösung mit minimalem Zeitaufwand implementiert werden kann. Denke nicht, tu es!

	14. XGH ist kein Trend.
	Scrum, XP? Das sind nur Trends. XGH Entwickler folgen keinen temporären Trends. XGH wird immer benutzt werden, von allen die Qualität verachten.

	15. XGH ist nicht immer WOP (Workaround-orientierte Programmierung).
	Viele WOPs benötigen schlaues Denken. XGH benötigt kein Denken (siehe Axiom 1).

	16. Versuche nicht gegen den Strom zu schwimmen.
	Wenn deine Kollegen XGH verwenden und du bist die einzige Memme, welche es richtig machen will, dann vergiss es! Für jedes Design Pattern, welches Du korrekt anwendest, werden deine Kollegen mit XGH zehnmal mieseren Code produzieren.

	17. XGH ist niemals gefährlich, solange du keine Ordnung darin siehst.
	Dieses Axiom ist sehr komplex, aber es besagt, dass ein XGH Projekt immer im Chaos endet. Versuche keine Ordnung reinzubringen (siehe Axiom 16). Es ist sinnlos und Zeitverschwendung. Dadurch wird alles nur schneller untergehen. Versuche nicht XGH zu organisieren, es ist eigenständig (siehe Axiom 11) und Chaos.

	18. XGH ist dein Kumpel. Aber es ist rachsüchtig.
	Während du es willst, ist XGH immer an deiner Seite. Aber pass auf, es niemals aufzugeben. Wenn Du etwas mit XGH beginnst und dann mit irgendeiner trendigen Methode weitermachst, bist du geliefert. XGH erlaubt kein Refactoring (siehe Axiom 10) und dein neues Weichei-System wird kollabieren. Wenn das passiert, kann dich nur XGH retten.

	19. Wenn es funktioniert, lass es in Ruhe.
	Ändere niemals - oder denke gar nicht erst daran - funktionierenden Code. Das ist absolute Zeitverschwendung und vor allem existiert kein Refactoring (siehe Axiom 10).
	Zeit ist der Motor hinter XGH und Qualität ist nur ein sinnloses Detail.

	20. Tests sind für Weicheier.
	Wenn Du jemals mit XGH gearbeitet hast, weißt du besser was du tust. Und wenn Du es weißt, warum dann testen? Tests sind Zeitverschwendung. Wenn es kompiliert, ist es gut.

	21. Gewöhne dich an das Gefühl gefählich zu leben.
	Erfolg und Misserfolg sind ziemlich ähnlich und XGH ist nicht anders. Die Leute denken normalerweise, dass ein Projekt eher fehlschlägt, wenn man XGH verwendet. Aber Erfolg ist nur eine Frage des Standpunkts.
	Das Projekt ist fehlgschlagen, aber Du hast dabei was gelernt? Dann war es ein Erfolg für Dich!

	22. Es ist nur dein Problem, wenn dein Name in der Code-Dokumentation steht.
	Fasse niemals eine Klasse an, von welcher du nicht der Author bist. Wenn ein Teammitglied stirbt oder zu lange weg bleibt, wird das Ganze untergehen. Wenn das passiert, nutze Axiom 8.

	### Gemeinschaftliche Ergänzung

	23. Mehr ist mehr.
	Mit XGH strebst du nach Code-Duplizierung - Code-Qualität ist bedeutungslos und für Codereviews und Refactoring ist keine Zeit. Zeit ist Geld, also Copy+Paste, schnell!
	eXtreme Go Horse (XGH) Process

	Source: http://gohorseprocess.wordpress.com


	1. I think therefore 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 way and the XGH way which is exactly like the wrong 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 only come to exist 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 commit always before updating.
	If things go wrong your part will always be correct... and your colleagues will be the ones dealing with the problems.

	7. XGH don't have schedules.
	Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the DB through some crazy script).

	8. Be ready to jump off when the boat starts sinking. Or blame someone else.
	For people using XGH someday the boat sinks. As time passes by the system grows into a bigger monster. You better have your resume ready for when the thing comes down. Or have someone else to blame.

	9. Be authentic. XGH don't follow patterns.
	Write code as you may want. If it solves the problem you must commit and forget about it.

	10. There's no refactoring just rework.
	If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem requires rewriting the whole software it's time for you to drop off before the whole thing goes down.

	11. XGH is anarchic.
	There's no need for a project manager. There's no owner and 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.
	Delivery dates and costs are absolute things. Quality is relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually, don't think. Do!

	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 10 times more rotten code using XGH.

	17. XGH is not dangerous until you see some order in it.
	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). It's useless and you'll spend a lot of precious time. This will make things go down even faster. Don't try to manage XGH as it's auto-sufficient (see Axiom 11) as it's also chaos.

	18. XGH is your bro. But it's vengeful.
	While you want it XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up. XGH doesn't allow refactoring (see Axiom 10) and your new sissy system will collapse. When that happens only XGH can save you.

	19. If it's working don't bother.
	Never ever change - or even think of question - a working code. That's a complete waste of time even more because refactoring doesn't exist (see Axiom 10).
	Time is the engine behind XGH and quality is just a meaningless detail.

	20. Tests are for pussies.
	If you ever worked with XGH you better 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 it's good.

	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. But success is just a way of seeing it.
	The project failed. You learned 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 the thing will go down. When that happens use Axiom 8.

	### Community addition

	23. More is more.
	With XGH you thrive on code duplication - code quality is meaningless and there's no time for code reviews or refactoring. Time is of the essence, so copy and paste, quickly!
	Fuente: http://gohorseprocess.wordpress.com

	Traducción originalmente de https://gist.github.com/upcesar/bfd685f12eb1dfb9eaa7176ab2642f4f

	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.

	### Adición de la comunidad

	23. Más es más.
	Con XGH prosperas con la duplicación de código: la calidad del código no tiene sentido y no hay tiempo para revisiones ni refactorización. El tiempo es esencial, ¡así que copia y pega rápido!
	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 .

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

	### Contribuição da comunidade

	23. Mais é mais.

	Com o XGH você prospera na duplicação de código - a qualidade do código não tem sentido e não há tempo para revisões de código ou refatoração. O tempo é essencial, então copie e cole, rapidamente!