¿Por qué tu producto necesita un buen código para funcionar? | la deuda técnica
¿Qué es la deuda técnica?
Muchos conocemos el concepto o significado de deuda en sentido económico. Todos hemos prestado dinero (o lo hemos pedido), y la mayoría de nosotros habremos usado una tarjeta de crédito en nuestra vida.
Una deuda, en términos económicos simples, es un compromiso de pago. Si no se devuelve ese dinero, las distintas entidades financieras activan intereses, que se pueden acumular, lo que puede provocar serios problemas a la parte prestada. La acumulación de intereses va cargando cada vez más una mochila que dificulta el progreso.
Si llevamos esta definición al ciclo de vida de la aplicación, esta deuda implica un código que, por motivos de presión en la entrega o por decisiones funcionales, no se ha implementado de la mejor forma, y que acaba precisando una refactorización posterior. Es el resultado de priorizar una entrega rápida por encima del código óptimo. A esto se le llama la deuda técnica.
Desde que se introdujo el concepto “Technical Debt” por Ward Cunningham a principios de los noventa, muchas veces los equipos de desarrollo se han referido al término como aquel mal que hay que evitar a toda costa durante el desarrollo de un proyecto. Sin embargo, la idea que expresaba Cunningham era más amplia: él defiende que un poco de deuda es buena y necesaria. Tal y como él lo expresó, “un poco de deuda agiliza el desarrollo en tanto que ésta sea devuelta reescribiendo el código”.
¿Qué tipos de deuda hay?
Martin Fowler, uno de los gurús de las buenas prácticas en el desarrollo de software, estableció un cuadrante para representar los distintos tipos de deuda técnica en función del contexto y la intención. Este cuadrante es muy útil mostrando que no siempre es malo generar deuda si se hace a cambio de tener entregas más rápidas.
Según Fowler, definimos las deudas técnicas como:
- Prudente y deliberada: Sucede cuando el equipo es consciente de que se están acumulando “intereses” a la deuda para centrarse en una entrega temprana, pero la decisión es aceptable si se gestiona más adelante. Es una estrategia muy equilibrada siempre que más adelante le dediquemos tiempo a reparar dicha deuda.
- Prudente e inadvertido: El equipo aprende cual debería haber sido la solución correcta después de la implementación. Como en el caso anterior, si luego este cambio necesario se implementa, se elimina esa deuda adquirida inconscientemente.
- Imprudente y deliberada: Cuando el equipo conoce las consecuencias y evita deliberadamente gestionarlas, priorizando únicamente la velocidad por encima de la calidad. Sin duda, la peor estrategia que se podría tener en el desarrollo de software.
- Imprudente e inadvertido: cuando el equipo no tiene experiencia e implementa la solución a ciegas. Un escenario totalmente indeseable.
Cualquier equipo que se encuentre en el cuadrante de la izquierda, el de la decisiones imprudentes, deliberadas o inadvertidas, terminará generando una aplicación que, si bien al inicio permiten entregar funcionalidades muy rápidamente, debido a la creciente complejidad del código los equipos de desarrollo tendrán cada vez más dificultades para escalar la funcionalidad o simplemente solucionar incidencias, las cuales, se pueden ver multiplicadas si no se han tomado las decisiones de arquitectura adecuadas durante la implementación.
¿Como gestionar la deuda?
Si un Product Owner deja que se acumule demasiada deuda, el proyecto entero podría caer por el peso de esta. Cuando realizar cualquier cambio, mejora o incluso resolver pequeñas incidencias se vuelve una tarea larga, complicada y tediosa. En consecuencia, la metáfora del dinero y los intereses deja de serlo, ya que el precio económico de mantener un producto con una alta deuda técnica se incrementa dramáticamente con el tiempo.
La deuda se asocia únicamente a consideraciones técnicas del código o la solución técnica, y por definición el Product Owner tiende a estar más focalizado en los aspectos funcionales. Por eso es especialmente importante que sepa escuchar al equipo técnico cuando le indique que cierta decisión funcional comporta deuda o que se ha estado acumulando demasiada de la misma.
Con el fin de mantener la cuenta de la deuda que conlleva un proyecto, cada vez que se encuentra un punto del código o funcionalidad que se traduce a aumentar la deuda, hay que añadir una tarea al Backlog para “pagar” esa deuda más adelante.
Cuando se visibiliza y estima, la deuda técnica se hace más difícil de ignorar y pasa a planificarse en las iteraciones de desarrollo posteriores para ir arreglando esas deficiencias o atajos que ha habido que introducir por ciertos requerimientos funcionales que requerían una entrega rápida.
¿Como arreglar la deuda?
No existen herramientas específicas para “reducir” la deuda técnica de un código. Hay que hablar de todo el abanico de herramientas y métodos que abarcan un amplio espectro de áreas dentro del ciclo de vida y desarrollo de una aplicación.
Frecuentemente nos encontramos buscando soluciones para la arquitectura de la aplicación, tipos de base de datos, procesos de integración y despliegue continuo, tests automáticos, seguridad, protocolos, y una larga listas de áreas en las que debemos tomar la decisión más adecuada. Ahí entra en juego nuestro conocimiento de las herramientas con las que trabajamos, el tiempo del que dispongamos, así como las necesidades funcionales, que siempre son lo más prioritario.
Debemos analizar las distintas opciones que existen en cada momento para determinar la solución óptima y estándar a un problema, desde los principios SOLID, patrones de diseño y código limpio, a frameworks de desarrollo, pasando por infinidad de librerías, servicios o lenguajes más adecuados para cada necesidad.
Aplicar las herramientas y patrones adecuados nos permite refactorizar nuestro código para ir eliminando esa deuda progresivamente y reducirla a unos niveles aceptables para mantener una evolución y mantenimiento sano de nuestro producto.
¿Qué deberías conocer sobre la deuda técnica?
Cuando se desarrolla un software, hay que asegurar un equilibrio entre los participantes del proyecto, desde desarrolladores a negocio. Esto implica un balance adecuado del triángulo de tiempo, calidad y coste.
Cada parte del equipo presiona hacía sus necesidades, pero la calidad, más allá que no existan bugs en la aplicación, no es siempre la más prioritaria ya que muchas veces no es visible desde negocio.
No obstante, no mantener la calidad del código acabará repercutiendo en los costes extra, que sólo aumentarán si no se reduce esa deuda por medio de refactorizaciones del código.
En definitiva, como esté hecho el código determinará la facilidad para que ese producto sea escalable, vendible, mantenible, testeable o traspasable a otros equipos de desarrollo. Finalmente, afectará al coste y tiempo de entrega de cada nueva funcionalidad, impactando directamente en los planes que tu empresa tenga para el producto si no satisface los requerimientos de coste y tiempo, ni por supuesto, calidad.
Encontrarás más artículos de interés en nuestro blog.