Tim es un programador experimentado. Trabaja en una empresa de software mundialmente conocida. A pesar de esto, en su extensa carrera Tim vio fallar a muchos proyectos, y sólo vio unos pocos proyectos exitosos. Después de 15 años de desarrollar software, Tim decide que quiere salir de las trincheras y empezar a gestionar proyectos. Tim está cansado de ver fallar a proyectos por motivos que podían evitarse. Se da cuenta que la única forma de arreglar estas cosas es ser él mismo la persona que tome las decisiones en estos proyectos.
Tim, como la mayoría de los desarrolladores, es una persona excéntrica. Es un entusiasta del código abierto y contribuyó en varios proyectos libres. Antes de escribir código en sus proyectos, usualmente pasa una hora haciendo yoga y continua con una meditación intensa. Después de meditar se da cuenta que puede escribir código más limpio y mejor diseñado.
Un día, mientras está meditando una idea le viene a la cabeza: "Quizás esta sea la solución para la crisis del software; todos necesitan meditar antes de escribir una línea de código". Y así nació el Desarrollo Guiado por la Meditación (MDD).
Tim va al trabajo y le cuenta a su equipo sobre esta nueva metodología. Como son buenos amigos de Tim deciden probarla. Tim espera pacientemente por algún proyecto donde pueda probarla.
El primer proyecto
Es el primer día de la fase de implementación del proyecto. Tim va en bicicleta al trabajo con más ganas de lo habitual. "Hoy va a ser el inicio de algo genial", se dice a si mismo.
Son las 9 de la mañana, y es hora de la primer reunión. Tim le pide a todos que se sienten en círculo en el piso, y reflexionan sobre un pasaje en particular de la Biblia. Al principio el equipo se sentía incómodo. No estaba seguros de qué hacer, pero bajo la cuidadosa dirección de Tim lograron un resultado. El equipo logra una meditación de 45 minutos y después ya están listos para escribir buen código.
Tim establece que todos los miembros del equipo tienen que meditar dos veces por día, una vez cuando llegan al trabajo y otra cuando vuelven del almuerzo. Cada meditación tiene que ser de al menos 45 minutos. Esto se hace sin excepción, todos los días del proyecto.
El proyecto estaba planificado para tres meses de duración, pero el equipo de Tim terminó todo el trabajo dos semanas antes. Además, el software que creó el equipo de Tim tuvo 20% menos de bugs que el promedio de la empresa. Tim concluyó que MDD era el responsable de estos resultados. "¡MDD funciona!", exclamó Tim.
Evangelizando
Dado su éxito inicial, Tim decide implementar MDD en todos sus proyectos. Y así repite el éxito. Su jefe queda impresionado y le pregunta porqué sus proyectos son tan exitosos. Para Tim, la respuesta es obvia: "MDD. MDD nos permite producir código de alta calidad, manteniendo costos y tiempos".
Tim convence a su jefe de implementar MDD en toda la empresa. Tim envía a sus discípulos a otros equipos para convertirlos a MDD. Lento pero seguro, la empresa se convierte a MDD.
Tim se da cuenta que otras personas podrían beneficiarse de MDD, así que firma un acuerdo con O'Reilly y escribe su libre transformacional "Desarrollo Guiado por la Meditación - El camino hacia un software más barato y confiable".
La reacción inicial es positiva. Al poco tiempo, hay varias personas que buscan a Tim para ayudarlos a implementar MDD, algo que está revolucionando la industria.
El manifiesto MDD
Unos dos años después de que Tim escribiera el libro sobre MDD, resultó claro que MDD estaba aplicándose mal en algunas empresas. Algunos equipos tenían problemas para que MDD les funcionara. Algunas personas no seguían las reglas del libro de manera correcta.
Tenían meditaciones de 20 minutos en vez del mínimo obligatorio de 45, y sólo lo hacían una vez por día! Tim exclamó: "¿Cómo pueden esperar que funcione la metodología cuando sólo meditan una vez por día?". Tenía que hacerse algo.
En este punto MDD se había fracturado en una serie de metodologías relacionadas pero levemente diferentes. Algunos preferían meditar con música, a otros les gustaba meditar escuchando poemas famosos. Otros preferían cuatro sesiones cortas por día en vez de las dos originales. Las diferencias importaban menos que los aspectos similares. Siempre y cuando hubiera una hora y media de meditación por día, todos los días, era MDD.
Tim y sus discípulos se sentaron juntos y crearon el manifiesto que unía estos diferentes enfoques de MDD bajo una filosofía común. Se comprometieron a transmitir el mensaje central de MDD y transformar la industria.
MDD se vuelve popular
Ya pasó una década desde que TIM escribió su libro. Una vez al año participa de "MDD-con" en San Diego. Publicó una serie de libros en el tema, y hace bastante dinero en consultoría sobre todo lo relacionado con MDD.
MDD es ahora una práctica conocida en la industria, con varias conferencias en todo el mundo. Es tan popular que hasta el más cerrado de los jefes escuchó sobre el tema.
Y sin embargo, no todo anda bien en la comunidad de MDD. Hay empresas comunes que tienen problemas reales para obtener los beneficios de MDD. Los proyectos siguen entregándose tarde, resultan costos y con bugs. La carrera de Tim se convirtió en la de un bombero. Su consultoría ya no es sobre adoptar MDD, sino sobre arreglar problemas en proyectos que ya usan MDD!.
MDD después de quince años
Ya pasaron quince años desde que TIM presentó su famoso libro. MDD es totalmente conocido y hay infinidad de equipos que lo usan. A pesar del éxito inicial de Tim, en promedio los proyectos MDD tienden a entregarse tarde, caros y con poca calidad.
Tim todavía promulga los méritos de MDD, pero encuentra poca satisfacción a donde quiera que vaya. Toda una generación de programadores creció con MDD y están desilusionados con proyectos que fallan, uno atrás de otro. Tim no puede entender porqué las personas tienen tantos problemas con MDD. ¡Tim sabe que MDD funciona! ¡Lo vio funcionar con sus propios ojos! En su mente, concluye que el problema debe ser que nadie lo está aplicando bien!
Un día, Tim se encuentra con un equipo liderado por una manager llamada Cathy. Los proyectos de Cathy se entregan a tiempo, sin pasarse del costo y con muchos menos bugs que el promedio de las empresas. Cathy tenía quince años de experiencia en el desarrollo de software y recientemente se había convertido en manager. Tim está muy impresionado por su éxito, y le pregunta cuál es su secreto:
"Es nuestra nueva metodología, QDD. QDD nos permite producir software de alta calidad, cumpliendo costos y plazos. QDD va a transformar nuestra industria".
Conclusión
¿Por qué MDD funcionó al principio y luego fracasó cuando se volvió popular? La razón por la cual MDD funcionó inicialmente no tiene nada que ver con las reglas de MDD. Tim era un desarrollador talentoso que trabajan en una empresa llena de desarrolladores talentosos. Casi cualquier metodología que puedan pensar iba a funcionar con estas personas.
Más aún, el equipo inicial de Tim habían sido elegidos por el mismo Tim. Eran las mismas personas que hubieran desarrollado software de alta calidad naturalmente de todas maneras. El único rol de MDD fue en ayudar al equipo a unirse, y una vez que lo lograron se convirtieron en un equipo increíblemente productivo. Tim se equivocó al identificar el origen de la productividad y se lo asignó a la metodología, en vez de pensar en su propia competencia y en al de su equipo.
Vamos a cerrar con un comentario de Robert Glass:
Lo importante en la construcción de software son las personas. Ese es el mensaje de este hecho en particular. Las herramientas importan. Las técnicas también importan. Los procesos importan. Pero por sobre todas estas cosas que importan están las personas.
Este mensaje es tan viejo como la misma industria del software. El mensaje apareció y aparece en tantos estudios de software e informes durante los años que hoy en día debería ser una de las "verdades eternas" del software. Y sin embargo lo seguimos olvidando. Pensamos en los procesos como el medio y el fin del desarrollo de software. Promocionamos herramientas como descubrimientos de nuestra habilidad para crear software. Juntamos colecciones diversas de técnicas, le ponemos el nombre de metodología, y le insistimos a miles de programadores que lean sobre esto, tomen clases, se lo aprendan con la práctica, y luego lo empleamos en proyectos críticos. Todo en nombre de las herramientas/técnicas/procesos por sobre las personas.
No caigan en la trampa de Tim. Los grandes desarrolladores crean gran software no porque siguen las reglas de alguna metodología, sino porque son artesanos verdaderamente capaces.