eXtreme Go Horse Methodology (XGH). !!!Arre caballo¡¡¡
Extreme Go Horse o Go Horse Process es una metodologías de desarrollo de software ficticia, repito !!!FICTICIA!!!, creadas por profesionales en la materia para satirizar la realidad que se vive en el día a día de las empresas de desarrollo de software.
Hace tiempo un amigo brasileño me hablo de la Metodología eXtreme Go Horse, me tomo la libertad de traducirla por Metodología Arre Caballo (MAC).
Me sorprendió, mi amigo es un tipo serio y responsable, y según leía no daba crédito hasta que caes en la cuenta que es pura ironía sobre ciertas formas de trabajar en el ámbito de la programación. Nada que ver con la realidad de lo deseable, pura SATIRA.
Pero hay momentos que da la sensación que va en serio hasta el punto que la pagina de referencia hay varias advertencias del tono jocoso de esta metodología, aun asi podeis encontrarla expuesta incluso en GitHub.
Proceso eXtreme Go Horse (XGH)´. Fuente: XGH Methodology. Comentarios y adornos del copista.
Pues vamos allá. Estos son los mandamientos del XGH
1. Pienso ... , pues si piensas por lo tanto no es XGH.
En XGH no piensas, haces lo primero que se te pasa por la cabeza. No hay una segunda opción ya que la primera es más rápida.
NOTA: Pues claro, de que nos extrañamos si empezamos así, al fin y al cabo, quien no lo ha hecho esto alguna vez en si vida. El primer impulso siempre es el bueno aunque sea una insensatez
2. Hay 3 formas de resolver un problema.
La forma correcta,
La forma incorrecta
... y la forma XGH que es exactamente igual a la incorrecta pero más rápida.
La forma correcta,
La forma incorrecta
... y la forma XGH que es exactamente igual a la incorrecta pero más rápida.
XGH es más rápido que cualquier proceso de desarrollo que conozca (consulte el Axioma 14).
3. Cuando empieces a usa la XGH, siempre tendrás que hacer más y más XGH.
Por cada problema resuelto usando XGH, se crean siete más. Y todos ellos se resolverán usando XGH. Por lo tanto XGH tiende al infinito.
4. XGH es completamente reactivo.
Los errores sólo existen cuando alguien los ve.
5. En XGH todo vale.
¿Resuelve el problema? ¿Se compiló? Lo entregas y no lo piensas más.
6. Haces commit siempre antes de las updates.
Si las cosas van mal tu parte siempre será la correcta... y tus compañeros serán los que se ocupen de los problemas.
7. XGH no tiene fechas.
Las fechas que le dan sus clientes son del todo irrelevantes. SIEMPRE podrá implementar TODO a tiempo (incluso si eso significa acceder a la base de datos a través de algún script loco).
8. Prepárate para saltar cuando el barco comience a hundirse ... o echale la culpa a alguien.
Para las personas que usan XGH, algún día el barco se hunde.
A medida que pasa el tiempo, el sistema se convierte en un monstruo más grande. Será mejor que tengas tu currículum listo para cuando la cosa baje ... o en su defecto, tener a alguien más a quien culpar.
9. Sea auténtico. XGH no sigue patrones.
9. Sea auténtico. XGH no sigue patrones.
Escriba el código como desee. Si resuelve el problema, haga commit y olvídese de él.
10. No hay reescritura, solo reelaboración.
Si las cosas salen mal, simplemente use XGH para resolver el problema rápidamente. Siempre que el problema requiera reescribir todo el software, es hora de que lo deje antes de que todo se apague.
11. XGH es anárquico.
No hay necesidad de un director de proyecto. No hay dueño y cada uno hace lo que quiere cuando aparecen los problemas y requerimientos.
12. Cree siempre en las promesas de mejora.
Poner comentarios "A HACER" en el código como una promesa de que el código se mejorará más adelante ayuda al desarrollador de XGH. Él/Ella no se sentirá culpable por la mierda que hizo. Seguro que no habrá reescritura (ver Axioma 10).
13. XGH es absoluto.
Las fechas de entrega y los costos son cosas absolutas.
La calidad es relativa. No piense nunca en la calidad, sino en el tiempo mínimo necesario para implementar una solución. En realidad, no pienses. ¡Hacer!
14. XGH no es una moda.
Scrum, XP? Esas son solo tendencias. Los desarrolladores de XGH no siguen tendencias temporales. XGH siempre será utilizado por aquellos que desprecian la calidad.
15. XGH no siempre es WOP (programación orientada a soluciones alternativas).
Muchos WOP requieren un pensamiento inteligente. XGH no requiere pensar (ver Axioma 1).
16. No intentes remar contra la corriente.
Si sus colegas usan XGH y usted es el único marica que quiere hacer las cosas de la manera correcta, ¡déjelo!
Para cualquier patrón de diseño que aplique correctamente, sus colegas generarán 10 veces más código corrupto usando XGH.
17. XGH no es peligroso hasta que vea algo de orden en él.
Este axioma es muy complejo ... pero dice que un proyecto de XGH siempre está en caos. No intente poner orden en XGH (vea el Axioma 16). Es inútil y gastarás mucho tiempo precioso.
Esto hará que las cosas bajen aún más rápido. No intente administrar XGH ya que es autosuficiente (consulte el Axioma 11) ya que también es un caos.
18. XGH es tu amigo. Pero es vengativo.
Mientras lo desees XGH siempre estará a tu lado. Pero ten cuidado de no abandonarlo. Si comienza algo usando XGH y luego recurre a alguna metodología de moda, estará jodido.
XGH no permite la refactorización (ver Axioma 10) y su nuevo sistema colapsará. Cuando eso sucede, solo XGH puede salvarte.
19. Si funciona, no te molestes.
Nunca cambie, ni piense en cuestionar, un código de trabajo.
Eso es una completa pérdida de tiempo aún más porque la reescritura no existe (ver Axioma 10).
El tiempo es el motor detrás de XGH y la calidad es solo un detalle sin sentido.
20. Las pruebas son para cobardes.
Si alguna vez trabajó con XGH, es mejor que sepa lo que está haciendo.
Y si sabes lo que estás haciendo, ¿por qué probar entonces? Las pruebas son una pérdida de tiempo. Si compila es bueno.
21. Estar acostumbrado a la sensación de 'vivir al límite'.
El fracaso y el éxito son realmente similares y XGH no es diferente.
La gente normalmente piensa que un proyecto puede tener mayores posibilidades de fracasar cuando se utiliza XGH. Pero el éxito es sólo una forma de verlo.
El proyecto fracasó. ¿Aprendiste algo con eso? ¡Entonces para ti fue un éxito!
22. El problema es solo tuyo cuando tu nombre está en los documentos del código.
Nunca toque una clase de código de la que no sea el autor.
Cuando un miembro del equipo muere o se mantiene alejado por mucho tiempo, la cosa fallará. Cuando eso suceda, use Axioma 8.
23. Más es más.
Con XGH, prospera con la duplicación de código: la calidad del código no tiene sentido y no hay tiempo para revisar o refactorizar el código.
El tiempo es esencial, así que copia y pega, ¡rápido!