La deuda técnica ¿buena o mala?

  • Mar 24, 17
  • Liberto Giménez

La deuda técnica permite que nuestros proyectos tecnológicos puedan desarrollarse hasta puntos y a velocidades que sin ella no sería posible. También, como con todas las deudas, es muy importante gestionarla correctamente o corremos el riesgo de que nos aboque al fracaso. Pero, ¿Qué es la deuda técnica? ¿En qué se diferencia del código malo? En esta techPill intentaremos explicar de forma rápida lo que es y lo que no es.

Cómo funciona

La mayor parte de referencias a la deuda técnica en software que podemos encontrar tratan sobre la calidad del código generado. Desde esa óptica, la deuda técnica se entiende como algo negativo, un coste oculto, un pago que se acabará realizando tarde o temprano por la utilización de código de poca calidad (código malo). Pero el concepto deuda no solo tiene connotaciones negativas. Gracias a las deudas podemos hacer cosas que sin ellas no podríamos.

 

En este techPill no nos ocuparemos en ese enfoque "tradicional" de la deuda técnica. Queremos tratar sobre la deuda técnica "buena", una utilización más estratégica de la deuda técnica: su uso consciente en las fases del diseño de los trabajos de programación, que es donde una buena gestión de la deuda técnica nos permite obtener un efecto positivo en nuestro proyecto.

 

Desde ese punto de vista, por deuda técnica "buena" se entiende la decisión de aplicar una solución de programación provisional que, sin ser la más correcta, nos permitirá llegar a un plazo de entrega o comprobar la aceptación de una nueva funcionalidad por parte de nuestro público objetivo de forma más económica. En primera instancia esto podría llegar a confundirse con código malo, una de las peores prácticas que se pueden dar en programación. Entonces ¿Cómo diferenciar el código malo de la deuda técnica "buena"? Rescatando la definición que acabamos de hacer vamos destacar las características de la deuda técnica "buena":

 

  • Decisión consciente: la utilización de la solución no óptima de programación es consciente y voluntaria. Es decir, se ha realizado un análisis previo de las posibles consecuencias de la utilización del recurso.
  • Es provisional: sabemos que la solución aplicada tiene fecha de caducidad. Somos conscientes que serán necesarios trabajos posteriores para saldar la deuda.
  • Nos aporta una ventaja competitiva a corto plazo: todo tiene un objetivo claro, obtener una ventaja competitiva que sin asumir esa deuda no sería posible alcanzar.
  • Sabemos que es una deuda: las deudas se pagan y no hacerlo o hacerlo fuera de plazo acaba comportando problemas. Es necesario de prever cuándo y cómo saldaremos la deuda.

 

En cambio, quien acaba generando código malo acostumbra a no ser consciente de hacerlo (está convencido que es código bueno), piensa que es definitivo y no es consciente de los pagos que deberá realizar posteriormente.

 

Un error común en muchos programadores es pensar que la deuda técnica es un recurso a evitar a toda costa. La deuda técnica, como todas las deudas, no siempre es algo negativo, hay que conocerla, medirla y gestionarla correctamente. Evitar la deuda técnica "buena" nos hace ser menos competitivos. Podríamos hacer un símil con una empresa uno de cuyos objetivos sea no endeudarse, tal vez jamas podrá renovar la maquinaria que hará que su productividad aumente.

 

Un ejemplo

Imaginemos que hemos desarrollado un CRM online para un cliente, una aplicación madura, multifuncional y personalizada con la imagen corporativa que con el tiempo ha adquirido un dimensión considerable. Un día por la mañana nos llama el cliente y nos dice abren una filial en Sudamérica y que necesitan que utilice el CRM pero con una imagen corporativa diferente. Lo necesitan ya (finalmente nos dan 2 semanas para llevar a cabo los cambios). Además nos hace una confidencia: en 3 o 4 meses se hará efectiva la adquisición de su mayor competidor y también necesitarán el CRM adaptado en este caso a su imagen corporativa y con algunos cambios de envergadura. 

 

Hacemos un estudio de los requerimientos: modificaciones el diagrama de entidades, permisos, plantillas gráficas, gestión de logos y colores corporativos, etc. Estimación de los cambios necesarios para incorporar la filial y la adquisición del competidor: 3 meses. Solo tenemos 2 semanas.

 

Tenemos dos opciones, o llamar al cliente y decirle que es imposible o recurrir a la deuda técnica. Pensando posibilidades se nos ha ocurrido una solución provisional que puede funcionar bien y que podríamos tener en 2 semanas: podríamos hacer que la gestión de plantillas gráficas fuera sensible al dominio de internet desde donde accedemos al CRM. Es una solución que sin grandes modificaciones permite que la aplicación muestre una u otra imagen corporativa, y por lo tanto es suficiente para incorporar la filial. No es la mejor solución y puede tener muchas limitaciones a largo plazo, pero en el corto nos ofrece una solución suficiente. Estamos incurriendo en deuda técnica.

 

Y ahora el pago de la deuda: una vez finalizadas las dos semanas de trabajos de implementación de la solución del dominio, tendremos que empezar a desarrollar una nueva versión del CRM con una gestión mucho más robusta de las diferencias entre compañías, tanto en lo que concierne a la imagen corporativa como en el resto de diferencias funcionales, permitiendo así también la incorporación del competidor adquirido.

Referencias