No persigas tu cola…

tiovivoErase una vez un grupo de desarrolladores que leyeron un post en un blog y  abrieron los ojos a la realidad: estaban empezando a programar demasiado pronto.

Su resultados eran buenos, incluso acertaban casi siempre con las necesidades del cliente. Lo sabían porque desde que ‘conocían’ las necesidades del cliente hasta que le mostraban los resultados de su esfuerzo no pasaba nunca más de un mes, y el cliente, salvo cierto feedback menor y algunas cambios de cierta entidad estaba satisfecho.

Y cuando esto no ocurría, y el cliente, por lo que fuese, necesitaba cambios como su código era excelente, estaban entrenados para escribir rápidamente código, y su proceso de desarrollo no les exigia demasiada burocracia, esto no era ningún drama. Además las pruebas y la construcción automatizadas les permitían tener la confianza de hacer cambios e integrar nuevo código sin impactar gravemente sobre la calidad general de la aplicación.

Planificaban cada una de las iteraciones que abordaban con cierto detalle, pero sin demasiado análisis y diseño detallado, con una reunión de vez en cuando frente a una pizarra era suficiente para aclarar los problemas que surguian… y eso no podía seguir así. El post lo decía claro: “Estamos ante una nueva ola de desarrolladores que creen que usar las metodologías ágiles significa pasar por alto el análisis, el diseño y todo lo que esté lejos del código fuente”. A nosotros nos pasa eso, pensó el equipo de la historia… nuestros resultados son buenos, pero podrían ser mejores. Debemos pensar más antes de escribir el código. Debemos iterar nuestros diseños…

Así que a partir de este momento vamos a mejorar nuestros diseños, debemos plasmarlos en papel, debatirlos, buscar diferentes soluciones. Debemos iterar nuestros diseños, es barato y al fin y al cabo ¡las iteraciones son un idea clave en todas las metodologías modernas!.

Por lo tanto, en lugar de juntarse simplemente en torno a una pizarra, ahora que tenían más tiempo y voluntad de analizar y diseñar, cada uno podría hacer su propio diseño, y luego discutir y consensuar la mejor aproximación. Y claro, decidieron, que después de esto, en otra iteración sobre la documentación de diseño, podrían analizar puntos fuertes y débiles de cada solución y luego, como es barato, total aun no han escrito código, podrían darle una nueva vuelta…

Esta vez, lo habían conseguido. No habían escrito código prematuramente. Habían consumido un tiempo bastante valioso, pero no pasaba nada. Tenían un diseño excelente, sin errores, revisado… nada podía fallar… bueno salvo lo de siempre, lo que siempre da problemas: el componente que no funciona como debe, el código que se vuelve inmantenible y que hemos de refactorizar, ese bug de la librería de creación de pdfs que nos cuesta dos días de quebraderos de cabeza, ese proceso de traspaso de datos que, a persar de su excelente diseño sobre el papel no da el rendimiento requerido… pero bueno, tenemos un gran diseño… Lo hemos cambiado eso si, en vista de los problemas que hemos tenido, pero anda que no era elegante oye, hay están los diagramas UML para demostrarselo a quien pregunte “¿pero que coño habéis hecho este sprint?” Analizar, Romerales, analizar…

Esta vez no iban a tener tiempo de hacer pruebas de carga, ni tiempo para fiabilizar el código, pero da igual, el diseño es tan bueno que seguro que esta vez no hemos introducido bugs, con todo el diseño que hemos hecho!!!

Iterar es un gran invento, sin duda, siempre que no se olvide para que se itera: para sacar conclusiones del pasado y planificar el futuro cercano. Algo de escasa utilidad cuando diseñas. Cuando diseñas, a menudo trabajas más con hipótesis que con certezas, y la única manera de validar esas hipótesis es implementándolas, testeando esa implementación y validándola con el cliente. Iterar sin ir adquiriendo conocimiento cierto, real y contrastable solo es perseguir tu propia cola… como hacen los cachorros. Sobre los diseños es, en la mayoría de los casos, es suficiente comentarles con otro miembro del equipo. Eso es suficiente iteración.

Pero claro, nos olvidamos de que los conceptos, los diseños y las soluciones no se ejecutan… y que el software solo es interesante por eso, porque se ejecuta.

La falacia es clara, si pensando un poco logramos hacer las cosas medio bien, pensando mucho las haremos excelentemente. En cinco minutos puedo tener un diseño aceptable, luego en cinco horas tendré un diseño excelente, parece ser el razonamiento correcto. El problema es que, en la ingeniería, del software hay miles de cuestiones que solo se resuelven cuando se realiza la implementación de la solución. Que tu arquitectura no da el rendimiento suficiente, por poner un ejemplo, es algo que a menudo solo descubrirás una vez que tengas una implementación.

Una implementación no tiene porque se un implementación definitiva, crear pequeños prototipos es a menudo imprescindible y de mucho más valor que simplemente ‘pensar’ un buen diseño, plasmarlo en papel y revisarlo exhaustivamente. Hoy por hoy los leguajes tipo python o ruby permite prototipar con gran facilidad.

No nos engañemos, ningún desarrollador del mundo escribe código sin pensar. Eso no pasa, no pasa porque es imposible que pase. Escribir código es algo que exige pensar. Ningún desarrollador, con un mínimo de experiencia, abordará el código sin diseñar, explicita o implícitamente. Y aquí es donde está la clave, aunque todo desarrollador diseña, no todo desarrollador lo hace explícitamente. Esta es la clave, hacer del diseño un proceso explicito, anterior a la codificación pero que siempre tenga como objetivo adentrarse en la codificación cuanto antes. Me vale escribir antes los test, o crear cuatro diagramas en una pizarra o un papel o si el problema lo merece reunirte con un colega o dos en torno a una pizarra… pero no debe nunca ser un proceso largo o poco ágil; no merece la pena.

Recuerda: algo de diseño es, la mayoría de las veces, suficiente diseño. Hay una gran diferencia entre no diseñar nada, y diseñar algo y diseñar en exceso. No diseñar nada es muy arriesgado. Diseñar en exceso, muy caro. Diseñar algo, lo más inteligente.

Siempre he desconfiado del jefe de proyecto que no ve nunca el código, del analista que no expresa los análisis con jerarquías de clases sino con cajitas, del arquitecto que no entrega esqueletos de soluciones sino power points… el código mueve el desarrollo, no los diseños.

Solo el software ejecutable muestra el avance de un proyecto. Lo que diferencia al desarrollo de software, de otras actividades humanas es que cada línea de código supone varias decisiones de diseño. En esas condiciones, no sirve de mucho el hacer mucho diseño a priori. Es mucho más efectivo implementar pronto y validar la implementación de manera temprana, continua y lo más automatizada posible.

Así que, parafraseando al autor del post que ha inspirado este: no creo que empezar a programar tarde mejore la calidad del código, del software o del proceso, exactamente, todo lo contrario…

6 comentarios en “No persigas tu cola…”

  1. Hola Rodrigo,
    Mira, yo trabajo en una empresa con ISO9000 y CMMI 5, pero no cualquiera sino la empresa que más confia en CMMI y los procesos definidos de desarrollo (en realidad la empresa no confia, solo lo hacen sus managers). Lo que decis pasa y de la manera mas irritante, lo que yo puedo hacer solo en 1 dia, en esta empresa se necesitan 7 ingenieros trabajando en papelerio durante 15 dias con un overload considerable si se quiere llegar a tiempo. Los continuos revisar y rehacer la documentación y el diseño sumada a la burocracia animal hacen que nadie quiera aceptar un cambio, ni siquiera uno insignificante como el título de una ventana. El ciclo de vida del software se vuelve un waterfall o un V (waterfall amariconado) y el tiempo de desarrollo no llega al 20%.
    Como la ves?
    Saludos. Y muy buena esta entrada.

  2. Totalmente de acuerdo! Pero para que sea efectivo se debe tener como respaldo una metodología acorde y no es tan fácil convencer a una empresa de que los métodos clásicos en cascada no funcionan.

  3. Daniel, sin duda apoyar tu proceso de desarrollo en una metodología es algo que aporta grandes ventajas. Pero no es algo imprescindible o que deba sustituir al sentido común.

    Tener que convencer a alguien implicado en el desarrollo de software de que las metodologías en cascada no funcionan es cuando menos desesperante.

    Lo más gracioso del tema es que el ciclo en cascada nunca ha existido. Los autores que lo propusieron siempre insistieron, en todos los ‘papers’ que escribieron sobre el tema, en que el ciclo en cascada debía repetirse iterativamente para que funcionas, pero por algún extraño motivo, todo el mundo decio obviar esa parte.

    Sobre CMMI, que voy a decir… si alguien sigue pensando que usando CMMI tal y como se implanta habitualmente se puede ser competitivo…

    Y digo tal y como se implanta, porque CMMI no es en si malo o bueno. Lo dañino es como se implanta, centrandose en recolectar ‘las evidencias’ que te pide el auditor y en pasar la auditoria no en mejorar realmente el proceso de desarollo. MSF for CMMI es una aproximación revolucionaria a CMMI, quiza por el objetivo que se marcaron de hacer la implantación más ágil posible de una metodología.

    De todos modos cada vez pienso más que lo que es ágil o no son los equipos, no las metodologías.

    Lucas, si en tu empresa los gerentes creen en CMMI y quienes deben llevar a cabo la metodología no esta no sirve de nada. Gerentes hay uno por cada veinte desarrolladores, la moraleja es clara, a quien debe convencer y ayudar una metodología es a los desarolladores no a los gerentes.

    El problema con CMMI es que es relativamente facil conseguir un sello sin realmente cambiar para nada tu proceso de desarollo o incluso cambiandolo a peor. Pero es igual, de puertas a fuera, tus clientes podrán creerse que tienes un proceso que garantiza resultados… aunque nunca hayas tenido resultados espectaculares. Esta es la clave de la cuestión, si te interesa más lo que el mercado percibe que lo que recibe, CMMI es un instrumento valido. No es necesario que tu proceso sea bueno solo es necesario que alguien certifique que lo es, la diferencia es notable.

    Gracias por leerme y comentar!!!

  4. ¡Genial!

    Mira que yo entiendo poco del tema este de las metodologías (más bien, para serte sincero, no creo en él), pero este post borda mi opinión sobre el “intermediario con la escoba en el c*lo” (son palabras de Fucowsky, no mías).

    Ahora resulta que currando solo (porque prácticamente curro solo, o me dan un protocolo ya predefinido y lo uso pero no lo implemento, o lo doy yo y lo implemento, y a veces hasta ambas cosas a la vez), resulta que aplico sin darme cuenta eso mismo.

    🙂

  5. Excelente este post Rodrigo y todos los que escribis, hace poco que te leo y son realmente muy buenos !!!

    Lamentablemente todavia no he visto a nadie que aplique UP de manera iterativa.
    En general he visto que estas cosas pasan mucho cuando hay analistas y managers que no conocen de desarrollo. Entonces para disimular su falta de conocimientos pretenden hacer de cuenta que en realidad no necesitan saber eso.
    Por aqui (cordoba-Argentina) abundan Analistas que creen que Analisar y diseñar aplicativos es mas o menos lo mismo. Le tiran a desarrollo unos papeles con su interpretación de lo que el cliente necesita, actuando como firewall entre el equipo de desarrollo y el cliente poniendo en extremo riesgo el proyecto. Sumado a esto, me ha tocado ver cosas tan terribles como que al desarrollador que no anda muy bien pasa a Analista y al analista que no anda muy bien lo pasa a lider de proyecto.
    Bueno, capas que me fui por las ramas pero creo que necesitaba descargarme.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *