La liebre y la tortuga

En este cuento voy a intentar explicar lo que significa programar rápido y lo que significa programar de forma ágil. La primera forma sería la que se considera comenzar lo antes posible, para terminar lo antes posible… pero ciertamente, sin planificación, dar palos de ciego a ciertos niveles de implementación, es más lento que planificar la estrategia de desarrollo a priori. Vamos a verlo con el cuento de…

La liebre y la tortuga

En Silicon Valley, había un programador tan rápido que podía escribir cientos y miles de líneas de código en cuestión de pocas horas, trabajaba rápidamente y, por ello, era conocido como la liebre. Aunque era un poco alocado, se lanzaba directamente a programar y no planificaba bien los proyectos.

No obstante, todos lo admiraban por lo rápido que hacía aparecer código en tan poco tiempo.

Por otro lado, estaba otro programador, algo más lento, que planificaba en papel y lentamente todos sus desarrollos, con lo que en un día obtenía muy pocas líneas de código. Este programador era conocido, por esto mismo, como la tortuga.

La liebre y la tortuga trabajaban en la misma empresa y, ante la fuerza que la admiración del resto ejercía sobre el primero, por su característica totalmente opuesta a la del segundo, la liebre instigaba e intentaba siempre perjudicar a la tortuga.

En la sala de trabajo, un día, cuando la tortuga ya se cansó de tanta hostilidad, aprovechó la oferta de un trabajo de programación importante, con un nivel de desarrollo importante y grande, para retar a la liebre: tú que eres tan rápido, te desafío a desarrollar este programa más rápido que yo.

Toda la sala quedó estupefacta, salvo el director de proyectos, que disimuladamente sonrió, agregando: sería interesante verlo. A lo que el resto de la sala agregó más risas.

El director de proyecto se dirigió a la liebre y le preguntó: ¿serías capaz de desarrollar este proyecto en menos tiempo que la tortuga? A lo que la liebre respondió sin dudar: ¡claro que sí! Pues os doy a ambos una semana para el desarrollo del proyecto, quien antes lo termine cumpliendo con los requisitos especificados, será el ganador.

La liebre comenzó a reir, aceptó el trato, al igual que la tortuga y fue a seguir riendo con sus compañeros durante largo rato mientras la tortuga marchó a su puesto de trabajo. La tortuga analizó el proyecto e inmediatamente localizó una serie de patrones claros que seguir, tomó los requisitos y trazó los diagramas que le harían cumplir con los mismos de la mejor forma, para seguir con una planificación ajustada al tiempo que tenía para cumplir con el proyecto. Se puso manos a la obra y comenzó el diseño.

Mientras tanto la liebre, se tomaba su tiempo y, mientras hablaba con sus compañeros decía: si ya sé cómo lo voy a hacer, es una chorrada de proyecto, ¡muy fácil!

En el segundo día, la tortuga terminaba su diseño con diagramas de UML, marcaba la división y los patrones que integrarían cada una de las clases, así cómo los detalles del diseño de interfaz y otras características a tener en cuenta en diagramas de secuencia.

Al tercer día, la liebre comenzó a codificar, en poco tiempo, tenía un trozo de código que cumplía los primeros requisitos y reía a gusto creyendo saber que conseguiría su propósito. Mientras, la tortuga, acababa de sentar el esquema de clases y la estructura básica, la arquitectura de soporte y preparaba todo para comenzar la codificación al día siguiente.

En el cuarto día, la liebre comenzó a encontrarse los primeros problemas, algunos requisitos chocaban directamente con muchas de las partes ya desarrolladas y en funcionamiento, así como datos ya implementados en la base de datos, con lo que se veía obligada a rehacer la estructura de datos, eliminar todo el código que no le servía y volver a escribir código nuevo. La tortuga comenzaba la codificación con la estructura de clases autogenerada por las herramientas CASE que usaba y trazaba las líneas de código de acceso a datos y lógica de negocio, escribía las pruebas unitarias para asegurar que todo salía bien y seguía adelante.

El quinto día, para la liebre, comenzaba el stress, la desesperación, se acerca el final del proyecto, aún no están todos los requisitos y se han vuelto a encontrar problemas. Como no hay una visión global, no sabe cuantos problemas más puede llegar a encontrar y, para los ya encontrados, la recodificación es algo pesada. Con lo que parece que solo lleva, de forma constante la mitad del proyecto. Por otro lado, la tortuga ha terminado la parte de lógica de negocio y manejo de datos, así como la parte de seguridad y acceso, el controlador, con lo que solo le restan las vistas, con las pruebas funcionales para acabar el proyecto.

El sexto día, cuando se había previsto la entrega del proyecto, la liebre había pasado toda la noche en su puesto de trabajo, intentando, con chapuzas, terminar a tiempo el proyecto, haciéndolo de forma muy deficiente y sin probarlo. Sin embargo, la tortuga, ya acababa la vista, haciendo siempre la ejecución de las pruebas de regresión para probar la integración de cada una de las partes, junto con las funcionalidades pedidas y el entorno en sí.

A la entrega del proyecto, la liebre presentó un proyecto con fallos, que no terminaba de funcionar y que tenía implementados los requisitos solicitados de forma dudosa, mientras que la tortuga entregaba un proyecto bien pensado, con un resultado limpio y funcional.

Ante los resultados, el director de proyectos se dirigió a la liebre y le dijo: no es cierto que es más rápido quien más rápido programa, sino quien, con menos código y menos trabajo, consigue hacer lo mismo en menos tiempo; y con ello, la tortuga ha demostrado, que es más rápido que la liebre.

Conclusión: usar metodologías ágiles acelera realmente el desarrollo, porque optimiza el proceso de creación.

No hay entradas relacionadas

7 Comments

  1. jonathan
    Posted 24 marzo 2009 at 18:31 | Permalink

    mu bueno! pero se te olvidó decir que la tortuga se quedó sin amigos en la oficina por despertar envidias y por llevarse tan bien con el jefe! :p

  2. Posted 24 marzo 2009 at 21:27 | Permalink

    Eso es que la tortuga era mu’buen trabajador y el jefe lo sabía :-D

  3. Posted 24 marzo 2009 at 22:27 | Permalink

    Una fábula ejemplificante y ejemplificadora… ¿podrías concretar qué herramientas CASE usaba la tortuga? Sé de un cachorro de elefante al que le gustaría ser más pesado y lento con el tiempo…

  4. Posted 25 marzo 2009 at 09:27 | Permalink

    Las herramientas CASE es un ejemplo de cómo una herramienta bien usada, puede escribir decenas de líneas de código por nosotros.

    Yo, personalmente, no suelo usarlas, aunque he jugado con generadores de Eclipse (desde diagramas UML), con el dia2code y otros similares.

    Veo que el tema de estas herramientas puede ser interesante para otra entrada :-)

  5. Posted 26 marzo 2009 at 23:24 | Permalink

    Sí, tienen que dar mucho juego. Yo he oido hablar bien de System Architect, Power Designer, Rational Rose… y dentro de Opensource y para UML, más concretamente, ArgoUML. Luego he visto por ahí una con la que se pueden hacer DFDs “no-tontos”, o sea, explotables (no planos como los de Visio) (easy-case, creo que se llama) pero muy antigua, codificada en VB, y en fin…
    No tengo mucha experiencia con el uso de estas herramientas ni soy desarrollador puro, pero sí que me gustaría saber de opiniones de gente que sí que las haya utilizado para así poder decidirme a implantar una en mi centro de trabajo.
    Por cierto, nunca había posteado antes, pero llevo siguiendo este blog unas semanas… mi enhorabuena, es realmente interesante.

  6. Posted 27 marzo 2009 at 00:47 | Permalink

    Gracias por tus comentarios, estoy recabando información sobre el tema de las herramientas CASE, en breve haré un artículo del estilo de ETL, espero tu retroalimentación :-)

  7. tonaly
    Posted 24 junio 2009 at 23:19 | Permalink

    chido cuento neta
    pz para los niños chikitos
    ps sta super bien