"The simplest thing that could possibly work"

Hola,

Yo creo que pensar hacia el futuro es una tarea positiva y que las metodologías ágiles lejos de criticarlo lo apoyan. La diferencia con ciertas metodologías tradicionales radica más bien en qué tipo de decisiones se deben tomar cuando se mira más allá de lo que podemos asegurar con certeza.

La práctica del diseño simple se apoya en dos principios de los métodos ágiles: tomar las decisiones lo más tarde posible (pero no más tarde) y la confianza en las personas.

Me explico con un ejemplo, al comenzar un proyecto de un año se prevé que va a hacer falta comunicarse con un sistema externo. Para ello parece que lo mejor es usar el producto X. Tanto en las metodologías ágiles con en las tradicionales es interesante hacerse este planteamiento. Pero la tradicional diría dedica el esfuerzo que sea necesario para decidir si ese es el mejor producto u es otro, y después intégralo lo antes posible. Por otro lado la ágil diría, si no hay una razón de mucho peso para introducirlo ya, mejor espera hasta el punto del proyecto en que dicha comunicación sea necesaria.

¿Qué ventajas tiene esto? Permite liberar al desarrollo de la carga de dicha integración inicial. De esta forma es posible producir resultados antes y avanzar más rápido dado que el sistema será más sencillo. Adicionalmente cuando se tome la decisión se tendrá un conocimiento mucho más cercano del problema y de la solución que se le está dando. Quizá en ese momento se concluye que la comunicación con ese sistema no es tan importante y se pueden obviar ciertos requisitos iniciales, o al revés, que es mucho más importante de lo esperado y hay que dar a los requisitos de calidad el mayor peso posible. Por otro lado será mucho más fácil determinar si el producto Y, que es casi tan bueno como el X será mucho más fácil de integrar en este caso. O aún más, quizá la tecnología ha evolucionado y ha salido otro producto aún mejor o alguno de los existentes se ha consolidado como dominador del mercado.

El problema con tomar las decisiones al principio radica en que es el momento del proyecto en el que se tiene menor información. ¿quién querría tomar una decisión en esas condiciones? Las metodologías ágiles te sugieren plantearte ¿no sería posible retrasar esta decisión? y proponen prácticas que puedes emplear para retrasar las decisiones hasta que dispongas de toda la información posible (refactorización continua, pruebas, planificación iterativa, etc).

¿Qué dificultades tiene retrasar las decisiones? Ya sean decisiones de diseño, de arquitectura, de tecnologías, etc. la principal dificultad es tener la habilidad y capacidad para determinar cuando es el momento adecuado y no retrasar la decisión más de lo conveniente.

Esto no aplica sólo aquí, en los métodos ágiles las personas tienen un papel central. Cuanto más capaz sea el equipo mejor saldrá el proyecto, por tanto es preferible invertir en capacitar el equipo que resignarse a usar metodologías para protegerse de la (a veces supuesta) falta de capacidad de la gente.

Dicho esto, cada caso particular es diferente. En tu caso, si trabajas sólo será muy fácil aplicar esta filosofía. Si trabajas en un equipo y aplicas la filosofía de un diseño simple verás cómo la comunicación con tus compañeros se facilita, pero habrá que adaptarla a la capacidad de tus compañeros. A la vez convendría apostar por capacitar al equipo y de esa manera se aprovechará mejor esta nueva filosofía.

Buenas,

En mi caso, llevo aplicando ese principio en algunos proyectos de desarrollo y normalmente resulta efectivo.

Uno de los problemas de las metodologías tradicionales ("pesadas") es que los cambios en el software que no se hayan tenido en cuenta en las primeras etapas del ciclo de vida son mucho mas costosos de incorporar. Es muy conocido el gráfico de coste exponencial en funcion del tiempo donde surjan los cambios. El subtitulo del libro que estas leyendo ("Embrace Change") resume muy bien la filosofía de XP: no oponerse a los cambios ya que estos son parte de la naturaleza de los proyectos de desarrollo de software. En lugar de esto, busquemos una forma de que los cambios tengan siempre el mismo impacto (o casi) independientemente de la etapa del proyecto en la que surjan.

Esto se consigue aplicando las practicas de XP (pero todas combinadas, porque su verdadera efectividad proviene de aplicarlas todas a la vez)
Una de dichas prácticas es la que tu mencionas: "Do the simplest thing that could possibly work". Si tu diseño es simple, será más facil de comunicar y de comprender, y de modificar si es necesario. Además, como tu comentas, muchas veces "complicamos" el diseño, aplicando patrones complejos con muchas clases y demás, encareciendo el desarrollo, la probabilidad de errores, etc. cuando finalmente no se necesita. Esto se conoce en XP como YAGNI ("You ain't gonna need it")

Pero como comentaba anteriormente, no podrías seguir esta filosofía si no estuviera acompañada de otras prácticas como la de "refactorizar frecuentemente" (para evitar la "degradación" del código y aplicar los patrones en el momento en que sean necesarios) o la de "collective ownership" para que cualquiera del equipo pueda modificar ese código para introducir los cambios, etc. etc.

Por lo tanto, te recomiendo busques la forma de aplicar las prácticas de XP, ya que todas están basadas en las lecciones aprendidas de tantos años de desarrollo de software. El tema que creo que debes tener en cuenta es que, dado que introducir XP implica un proceso de aprendizaje y de cambiar ciertos conceptos que traemos desde hace mucho tiempo, busques un proyecto propicio para poder llevarlo a cabo con XP: que sea pequeño, con un equipo reducido y no demasiado crítico. Tambien creo que es muy aconsejable el acudir a otras personas, ya sea a través de foros o buscando algún consultor.

Espero que mis comentarios te hayan sido de utilidad.

Saludos,
Rodolfo

En mi experiencia cualquier decisión prematura (que puede ser de diseño, de integración, de interfaz, de optimización, etc. o incluso de tipo comercial) en desarrollo software será seguramente inadecuada o a lo sumo sólo parcialmente adecuada. Este es el mayor contraste y el mayor reto con respecto al resto de las ingenierías, las cuales se apoyan fuertemente en la anticipación y la experiencia previa.

Pero, como todos sabemos, tomar las decisiones al final o demasiado tarde es igualmente negativo

¿Cuándo es entonces el mejor momento? ¿Hasta cuándo hay que esperar? Pues hasta el preciso momento en que podamos obtener un "feedback" inmediato de esa decisión que nos permita cuantificar en el presente su idoneidad o no. Se tiene que tratar de un proceso incremental, en continuo cambio, adaptativo, basado en prototipado continuo, y por supuesto necesariamente ágil.

Pongamos un ejemplo, imagínate que piensas que el sistema que vas a implementar podría beneficiarse de un diseño basado en plugins. No es necesario que deseches la idea, simplemente espera, primero a tener una primera versión del sistema sin plugins, luego otra versión con una primera extensión que podría o no ser candidata a ser un futuro plugin. Será en este momento cuando estés en condiciones de evaluar el beneficio real de saltar a un diseño basado en plugins o por el contrario ese aumento de complejidad no está realmente justificado.

Hay además un valor añadido, y es que la gratificación y confianza que produce adoptar una solución de diseño que simplifica y mejora un diseño ya existente compensa con creces el tener que haber implementado este último antes. Eso sin contar el poder evitar la decepción que produce comprobar que una decisión tomada prematuramente resultó no ser tan positiva.