eXtreme Go-Horse Process

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!