Este podría ser uno de los capítulos extra de El Libro Negro del Programador. En demasiadas ocasiones veo la siguiente dinámica de trabajo (en la que yo también, por supuesto, he caído muchas veces, aunque ya menos): trabajamos en un proyecto y nuestra principal obsesión consiste en añadir funcionalidad, nuevas características, ahora esto, ahora aquello, y así durante meses cuando creemos que estamos avanzando.

Puesto que ese es seguramente el aspecto más atractivo como desarrolladores de software, eso mismo es entonces lo que hacemos, y disfrutamos viendo crecer la aplicación con nuevas características, para nuestro gozo, disfrute y satisfacción. Por el momento, los desarrolladores contentos, el negocio y el cliente, también.

Todo "parece" ir sobre ruedas, como esas relaciones que aparentan ser la pareja perfecta pero que luego en la intimidad se tiran los trastos a la cabeza, esto es, algo hay podrido en alguna parte que terminará por estallar el momento menos pensado.

Volviendo al proyecto software, puede que no te hayas dado cuenta de lo que se está gestando y que hasta veas esa situación como normal, porque para eso nos pagan, ¿no?, para hacer que algo funcione y le dé utilidad a alguien, añadiendo más funcionalidad e implementado los requisitos.

Pero del mismo modo, sin darte cuenta, estás plantando la semilla del caos en tu proyecto, sobre todo si éste tiene una vida de muchos años e infinidad de cambios que soportar, o incluso ni sospechas el tipo de cambios que se van a exigir a medio plazo, que suele ser lo habitual. 

¿Hay algún negocio acaso que sepa de dónde va a venir su crecimiento en unos años? Son muy pocos los que pueden tener una idea de ello. Esto es, si la aplicación que construyes va a soportar a dicho negocio, no tenemos ni idea de la forma en la que va a evolucionar.

Pasa el tiempo, la aplicación o sistema crece desorbitadamente y nos encontramos viviendo en un caos constante. El crecimiento orgánico descontrolado del sistema ha creado un monstruo inmanejable.

Este caos puede venir de diferentes formas: un sistema cada vez más frágil (tocas aquí y algo se estropea allí), funcionalidad añadida con demasiada celeridad sin respetar la forma de hacer las cosas en ese proyecto (esto es, sin seguir el diseño, si es que lo hay claramente), necesidad de pasar demasiado tiempo para cambiar cualquier detalle (el tiempo es dinero, coste para el proyecto que alguien tiene que pagar), y, como por arte de birlibirloque, llega un momento en que añadir / poner / quitar algo en el proyecto se convierte en una auténtica pesadilla, y echamos de menos entonces el momento aquel en que lo comenzamos con tanta ilusión, cuando el bebé aún no se había convertido en ese adolescente rebelde e insufrible...

Al cabo del tiempo, tienes que mantener un sistema frágil, muy acoplado y con un diseño más monolítico que flexible.

Esto es: el crecimiento orgánico de un proyecto de forma descontrolada conduce a un proyecto espagueti y costoso de mantener y evolucionar. ¿El resultado? Desarrolladores frustrados y responsables que en algún momento tienen que defender ante la dirección volver a hacerlo todo desde el principio, pero "mejor". En ocasiones, hasta se defiende una nueva "versión" cuando en realidad se trata de tirarlo todo a la basura y volver a construir el sistema desde el principio.

La cuestión que quiero plantear aquí es por qué se produce esta situación insostenible, situación que he vivido trabajando con algunos de mis clientes y reconozco que no es para nada agradable.

La dinámica es bien conocida: añadir más y más funcionalidad de forma casi descontrolada porque el tiempo apremia y el negocio necesita ya toda esa funcionalidad que exige, aumentando la bola de nieve hasta que llega un momento en que ésta nos aplasta.

La forma de evitarlo es también bien conocida.

Este es un principio universal en software: el coste de actuar al final (cuando ya es demasiado tarde) es mucho mayor que actuar repetidamente a lo largo de la vida del proyecto para evitar la situación anterior.

Pero, actuar... ¿en qué exactamente?

Es lo que yo llamo realizar "paradas técnicas", sobre todo, insisto, en proyectos o productos que deben tener una vida de años.

No hay más, esta es la receta: parte de nuestro tiempo de trabajo debe enfocarse en mejorar el diseño y arquitectura de la solución.

No hablo de hacer pequeñas mejoras en el día a día limpiando esto y aquello, refactorizando aquí y allá. Hablo de pasar un tiempo dedicado exclusivamente a analizar integralmente la solución para encontrar y sintetizar mejoras que permitan su crecimiento de modo mejor y más ordenado.

Estimo que a esta actividad hay que dedicar aproximadamente un cuarto del tiempo disponible al trabajar en un proyecto de largo recorrido.

Así es, puede parecer mucho tiempo, pero mi experiencia me demuestra que este paso atrás aparente, permite después avanzar mucho más rápido consiguiendo una solución mantenible y de mejor calidad (y con menos coste).

Lo he visto: si te dedicas a añadir funcionalidad continuamente, sin pararte a reflexionar si el diseño y la arquitectura se van ajustando a ese crecimiento funcional, tarde o temprano tendrás una patata caliente sobre la que alguien tendrá que responder.

Dedica uno de cada cuatro o cinco sprints o ciclos de trabajo a asentar la funcionar ya existente (parada técnica), mejorando cualquier aspecto que creas conveniente, refactorizando aún más el diseño, mejorando la arquitectura y los procedimientos de gestión de la configuración y despliegue. Puede parecer que ese esfuerzo es un gasto (ya que no añade nada nuevo al sistema), pero el tiempo te demostrará que ese esfuerzo reducirá drásticamente los problemas en el futuro y permitirá añadir más características más adelante con menos dificultad.

Igual que la regla de pareto 80/20 (que viene a decir algo así como que el 80% de los resultados vienen de un 20% del esfuerzo), en software afirmo que el 25% del tiempo de trabajo debe dedicarse a mejorar el sistema actual para permitir su crecimiento futuro, al menos en los proyectos que deben durar años de desarrollo con una gran cantidad de cambios.

Un paso atrás (en apariencia) pero que nos permitirá dar varios adelante con mayor certeza, seguridad y calidad.

 

Comparte esta entrada...

Todos los libros de Rafael Gómez Blanes

Todos mis libros técnicos

Si quieres conseguir una carrera de éxito desarrollando software y saber cómo evitar los errores habituales, lee El Libro Negro del Programador best seller en su categoría en Amazon), o adquiérelo ya aquí.

Si quieres conocer las principales técnicas de desarrollo ágil, código limpio y refactoring, lee El Libro Práctico del Programador Ágil, o descárgalo ya aquí.

Si estás de acuerdo conmigo en que somos seres de hábitos, conviértete en mejor profesional leyendo The Coder Habits, o consíguelo ya aquí.

Los tres libros técnicos los tienes ahora a tu disposición en el pack La Trilogía del Programador Profesional, léelo ya.

Si tienes un proyecto que gestionar y no sabes cómo, aprende metodología lean y lee El Método Lean MP, o adquiérelo aquí.

Desde junio, El Arte del Emprendedor Digital

 

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

Trabajo en...

Archivo

Mis novelas...