No persigas tu cola...
Erase 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...