Barrapunto

A mí me parece que tiene bastante de exageración para vender libros, pero tiene algunas ideas interesantes. En concreto, me gusta lo de empezar con los tests: te ayuda mucho a centrarte.

Lo de programación por parejas creo que puede ser positivo: siempre da más vergüenza hacer una chapuza cuando te está viendo otro. Aunque, claro, si el otro es tan chapuzas como tú, igual os reforzáis mutuamente. En cualquier caso, que otra persona mire tu código me parece fundamental.

En lo que no estoy tan de acuerdo es en que lo plantean como algo radical y yo creo que hay ser más flexible y pensar que se puede combinar con metodologías más tradicionales. Tampoco estoy de acuerdo en que siempre haya que hacer lo más sencillo: a veces hay que mirar un poco más allá y lo que es más sencillo ahora puede ser un rémora para el futuro.

No tengo experiencia programando profesionalmente, pero sufro los efectos de los tipos de programación utilizados por las empresas. Las empresas que conozco usan una forma de programar, que se que no es nueva, denominada programación de mierda.
    Esta forma de programar consiste en cojer a unos cuantos recien licenciados, pagarles muy poco e intentar que acaben en unos plazos demasiado cortos, incluso para programadores experimentados. Si a esto añadimos una rotación en los programadores muy alta, ....
    El resultado es un producto mal diseñado, pero desarrollado, y que se prueba en entornos de producción por el agotamiento de los plazos.

No se dónde se usará la Programación XP, pero en mi mundo sólo se usa el tipo de programción que acabo de describir.

Te faltaba una e antes de Xtreme, pero bueno, eso es lo de menos. A lo que me vengo a referir es que yo he utilizado esta metodología al hacer mi proyecto final de carrera (que leo dentro de unos días) Es una metodología "ágil", me explico, es útil para proyectos en los que no se ha hecho una definición de requisitos clara y se requieren reuniones constantes con el cliente (más o menos las iteraciones duran dos o tres semanas lo que trae consigo dos reuniones mensuales cn el cliente más o menos). La verdad es una metodología un tanto utópica porque se basa en una premisa que dificilmente se puede cumplir: que el cliente sea una parte más del equipo de desarrollo. Por lo demás es muy interesante ya que considera fundamental el "feedback" (realimentación o retroalimentación no he conseguido una definición estándar) y las reuniones de proyecto entre directores y desarrolladores.

por si alguien está interesado en ver las cosas comunes entre Programación eXtrema y Software Libre [ultimaorbita.com].

No estaría mal que se incluyera una pequeña explicación en la noticia de qué es la programación extrema, porque no me considero ningún novato en temas de programación, y he leído ésto [extremeprogramming.org], y casi sigo igual.
Es que son muchas veces que en las noticias de BP una frase explicando muy brevemente de qué se está hablando nos ayudaría a saber de qué trata la noticia a muchos.

La idea que subyace en la Programación Extrema es la de aplicar el Método Cientifico a la metodología de la programación. Para su postulación se analizaron diferentes proyectos de desarrollo existosos y trataron de ver empíricamente aquellas características comunes que tenían. Las doce actividades que postula la programación extrema son estas características deducidas "empíricamente", y se consideran esenciales para que un proyecto pudiera ser exitoso. Estas actividades deben estar siempre presentes, y entre ellas debe existir un equilibrio tal que las deficiencias en una de ellas exigen más efuerzo en el resto de actividades.

Siempre se identifica a la XP con la programación por parejas, aunque hay otras actividades que me gustan mucho más como que la "jornada laboral es de 40 horas", sin horas extras (es importante para el proyecto dedicarle tiempo a la familia). Concretamente, la programación por parejas es una práctica que se vió que era muy buena porque, por un lado el programador que codificaba lo hacía para que el otro lo "entendiera", mientras tanto el otro (casi siempre callado y sin hacer críticas ;-) estaba ya pensando en los casos de prueba que iba a crear sobre ese código que estaba viendo crecer. Lejos de ser un "desperdicio" por tener un programador parado, resultó ser una buena forma de asegurar que la aplicación cumpliría con las especificaciones funcionales. Hay mucho más, y recomiendo leerse los porqués de las doce prácticas.

Pido abstracción del lenguaje, hablemos de modelos un poco.

Esto es, imho, muy difícil (imposible?) de lograr. Los lenguajes tienen un FUERTE impacto en la forma de trabajar y un FUERTE impacto en el resultado producido.

Comenzando por:

• diferencias de paradigmas (Objetos, Funcional, Lógico, etc)
• pasando por el tipo de "detalles" de implementación a los que debemos someter nuestro código (manejo manual de memoria, early vs late binding, tipado fuerte o débil, etc)
• y terminando el tipo de soporte que nos dan los entornos de programación (comenzando por echo "main()" > hello.c, pasando por el vi/emacs y terminando en un ambiente como los que el Smalltalk, Lisp o Prolog brindan)

Es fácil darse cuenta que no se puede hablar de una metodología en particular sin considerar las herramientas.

El eXtreme Programing fue formalizado por Kent Beck, en su famoso libro blanco de XP, después de sus años de experiencia usando Smalltalk y no es más que una descripción detallada de las prácticas de programación que los Smalltalkers vienen siguiendo hace más de 30 años. Los invito a leer una nota que salió en la revista byte de agosto de 1981 [1] donde Dan Ingalls (uno de los padres del Smalltalk) nos cuenta las motivaciones del proyecto y verán allí las semillas del XP.

[1] Principios de Diseño de Smalltalk [smalltalking.net] o Design Principles Behind Smalltalk [ipa.net]

1. El de mercadeo vende un software que permite una nave superar varias veces la velocidad de la luz.

2. El Gerente se muestra orgulloso y aparece en pose orgullosa en varias fotografías en diversas publicaciones sobre el hito de superar la velocidad de la luz varias veces.

3. El Jefe de Proyecto se dedica con Microsoft Project a jugar con los colores y hacer el cronograma bien llamativo.

4. El asistente del Jefe de Proyecto hace uso de PowerPoint y hace bonitas y espectaculares diapositivas sobre el proyecto.

5. El de recursos humanos prepara aburridas charlas de motivación y por supuesto los contratos que amenazan al pobre programador de quitarle su alma si no logra el objetivo.

6. El de calidad prepara mas de 1000 formatos de ISO9000 para que sean llenados por el pobre programador.

7. Y finalmente el pobre programador es un recien egresado con cero experiencia que deberá resolver semejante lío y que si no lo hace pierde su alma y será almorzado por todos los jefes. Deberá trabajar horas extras, festivos, deberá renunciar a toda vida social y le pagarán solo un 0,000001% por encima del mínimo.

8. Para que trabaje mas al pobre programador le prohiben el acceso a internet y al correo electrónico. Deberá pagar de su propio dinero las revistas, libros, etc.. que requiera para hacer el trabajo.

9. El pobre programador deberá llenar un formato que especifíque minuto a minuto lo que hizo en el día.

10. Si el programador dice que no es posible superar la velocidad de la luz corre el riesgo de ser tachado como un incompetente y es amenazado con tirarlo a la calle con el argumento de que "cientos de miles de millones de programadores trabajarán mucho mas por mucho menos".

Y los abusos no terminan nunca porque el programador no tiene derecho a protestar.

La gente se centra demasiado en lo de la programación por parejas y yo creo que es lo de menos.

En mi opinion, esto es lo mejor:

• Ciclos de desarrollo muy cortos y un feedback más frecuente con el usuario de tu apliación (tu cliente!).
• Desarrollo orientado al Test (TDD, Kent Beck): escribe los unit tests incluso antes de escribir el código.

Y lo peor, que esta metodología destila la idea de que se puede empezar a escribir código sin apenas gastar un segundo en la fase de análisis y diseño. Algunos ven esta metodología como una "licencia para tirar líneas" sin hacer análisis, y esto es pasarse. Claro que el arte del analista profesional está en saber encontrar el equilibrio...

Con esta metodología no he tenido mucha experiencia hasta ahora, pero he usado uno de sus principios que es la programación por parejas cuando realizaba mis programas para la universidad. La verdad que en mi caso no presento ventajas significativas, ya que mi compañero era mas lento que yo para entender y escribir codigo, asi que yo por lo general era el que estaba en el teclado, me di cuenta que fue una perdida de tiempo porque a lo mejor en ese tiempo que mi compañero estaba viendo lo que yo escribia hubiera podido él escribir otra parte del programa por mas que fuera un poco mas lento, ya que cuando miraba mi codigo no estaba produciendo nada y con respecto a los errores hubo una mejora en el tiempo en que los encontrabamos y solucionabamos, pero no compensaba el tiempo que perdiamos. Alguna vez lei que un programador con experiencia no se diferencia de un programador novato en el hecho de cometer menos errores, sino que comete aproximadamente la misma cantidad y tipo de errores, solo que encuentra la solución a los mismos de manera mucho mas rapida....y es algo que yo he podido comprobar con mi evolución como programador. Por esto digo que la programación por parejas puede ser ventajosa para cuando uno de los programadores necesita aprender del otro o ambos estan aprendiendo, pero no creo que dos programadores con mucha experiencia y con dominio del lenguaje y el diseño del programa vayan a ser mucho mas productivos que trabajando individualmente....creo que seria un desperdicio de tiempo y recursos, y las ventajas aparentes se diluirian. Esta es mi experiencia personal, pero para quien quiera mas sobre esto aca les dejo un link a un documento que expone criticas fundamentadas contra la programación extrema, con una muy buena introduccion a las metodologias agiles para quien no sepa de que cosa estamos hablando. Es un punto de vista mas que interesante, en el que basicamente el autor dice que esto es una moda para "vender" libros y que todavia no hay proyecto de envergadura que haya sido terminado aplicando la metodologia XP. http://www.javahispano.org/download.download.actio n?type=tutorials&id=34 PD: algunas cosas que se proponen en las metodologias XP son muy intersantes, pero son cosas que ya se sabian y aconsejaban hacer desde hace mucho tiempo. Saludos a todos.

Curiosamente este mes hay una crítica bastante buena al XP en Dr.Dobb's (edición impresa [ddj.com] :( ), resumo:
XP es una colección de 12 buenas prácticas, se mete con 6 relacionadas en cadena.

* No hay requerimiento del cliente detalladamente escritos, estos consisten en "story cards" escritos a mano... una descripción del comportamiento del cliente. Estas descripciones no son muy detalladas y se pueden cambiar a lo largo del desarrollo, la teoría dice que el programador puede preguntarle al cliente cuando está centrado en el desarrollo de uno de estos "story cards". Como no existe una descripción detallada de los requerimientos, no es posible hacer un diseño detallado... lo que nos lleva al...

* Diseño rápido, rápidamente ir al código. Al no pensar en el diseño el tiempo suficiente el código se vuelve espaguetti, lleno de trucos a medida que el diseño evoluciona.

* Refactorizar tras programar, debido a que no se gasta suficiente tiempo en el diseño hay que gastar mucho en la refactorización del código (mejora del diseño de código existente). La refactorización tiene el peligro de introducir bugs (al extraer métodos, introducir parámetros, moviendo cosas), lo que se compensa con los test unitarios.

* unit testing, diseñando después de probar, el ciclo es: escribir tests, escribir código, ejecutar los tests, y por último refactorizar... con el peligro de tener que escribir tests para código que puede desaparecer en una de las iteraciones.
  Todos estamos a favor de los tests unitarios, pero los tests no puede chequear la corrección del diseño. Lo que compensa el diseño errático y erroneo es la práctica de la programación en parejas.

* Pair Programming, generalmente en los proyectos (y especialmente en estos sin grandes especificaciones de diseño) los programadores se hacen expertos de su parte, con la programación en parejas y la rotación de las parejas se intenta que todos los miembros del equipo tengan un conocimiento completo del proyecto (suena bien, ¿enh?), lo malo es que es idealista. Si algún código tiene un bug serio ¿quien es el responsable? "--in short, who gets fired?".

* Collective Ownership (Propiedad colectiva) , es una espada de doble filo, por un lado el código malo será corregido por alguien cuando lo vea, pero nadie es realmente responsable de nada.

  La teoría de XP dice que la comunicación suplanta al diseño muy definido, lo que puede llevar a que los desarrolladores empiecen escribiendo algo que se aleja bastante de lo que los clientes realmente quieren. Lo que se compensa con la presencia del cliente en el proceso de desarrollo (lo que a mi me parece ciencia ficción).
Una de las razones de incluir al cliente en XP es para incrementar el desarrollo "ágil". El cliente ve el desarrollo en un plazo de tiempo muy corto y ofrece un "feedback" inmediato. Lo que puede llevar a cambios de requisitos, cuando el cliente ve como se va comportando el producto... lo que lleva a problemas con las especificación del diseño y al peligro de entregar fuera de tiempo.
La falta de especificaciones nos lleva al principio del artículo...

La conclusión del autor es que los problemas que intenta resolver son los mismos que crea. XP se vende como una metodología ligera, pero la realidad es que XP requiere una gran disciplina de cada miembro del equipo. Lo que la hace todo menos ligera... finaliza diciendo que XP no es una metodología que se pueda recomendar :)