¿Recuerdas algún proyecto que salió mal porque aparecían errores por todas partes? Seguro que ya te han venido a la mente unos cuantos flashbacks de guerra: aquel proyecto de grandes dimensiones, el que no lo era tanto pero aún así duró meses, un pequeño script que nunca llegó a funcionar…

Aunque a veces no nos demos cuenta o en ocasiones no queramos verlo, lo cierto es que cuando nos encontramos en esta casuística, tanto el Programador como Project Manager o cliente tienen cierto nivel de culpa. Al final da igual el papel que desempeñes dentro un proyecto, porque cuando lo que estás haciendo no sale bien siempre da como resultado una situación muy incómoda para todos los actores que participan.

Pero… ¿y si te digo que existe un concepto que define porqué ocurre esto? Es aquí donde entra la Deuda Técnica, término acuñado por Ward Cunningham, que utiliza el símil de la Deuda Económica para explicarla.

¿Qué es la Deuda Técnica?

Pongámonos en situación: diriges una empresa que quieres hacer crecer. Para ello, contraes una deuda que tiene cierto interés y que debes pagar de forma mensual. Si pagas mes a mes sin retraso los intereses a liquidar son mínimos, pero si no lo haces aumentan por el impago.

Vale, hasta aquí lo tenemos claro, ¿y ahora cómo podemos aplicar esto al mundo del software? Muy fácil, sustituye capital por código e intereses por errores o code smells de forma que cuantos más problemas dé nuestro código, más tiempo debemos invertir en desarrollar nuevas características o solucionar los problemas del sistema.

Hacer frente a esta deuda no es una cuestión de volverse loc@ corrigiendo errores, pero sí que es verdad que aunque no exista un código 100% limpio a ojos de todo programador o programadora, existe un código en el que un profesional que lo revise advierta cierto foco en la legibilidad, simplicidad y bajo acoplamiento de la persona que lo ha escrito.

Por ello, debemos tener especial foco en identificación, comunicación y la corrección de estas problemáticas.

Los 4 cuadrantes de la Deuda Técnica

«El objetivo de un buen diseño y un código limpio es poder hacer que vaya más rápido; si no fuera así, personas como el Tío Bob, Kent Beck y Ward Cunningham no perderían tiempo hablando de ello».

Martin Fowler

Martin Fowler formó su propia opinión sobre la Deuda Técnica y diseñó los 4 cuadrantes que la conforman donde explica cómo puede estar actuando un programador o programadora cuando desarrolla el sistema. Tomando como referencia este cuadrante, Fowler establece que el eje vertical indica si un desarrollador actúa de manera deliberada o inadvertida, y el eje horizontal indica si actúa de manera prudente o imprudente.

Deuda Imprudente e Inadvertida

El desarrollador desconoce de la existencia de buenas prácticas de programación, por lo que es el tipo de deuda más común entre perfiles Junior. De esta nace la necesidad de llevar a cabo la supervisión del trabajo por parte de un Senior o Semi-Senior.

Deuda Imprudente y Deliberada

En este caso, los programadores saben que no están haciendo el mejor código posible para desarrollar un software de calidad, por lo que dejan a un lado las buenas prácticas de programación pensando que se adquiere mayor velocidad de desarrollo al poder ver resultados antes.

Deuda Prudente y Deliberada

El desarrollador aplica buenas prácticas de programación y es consciente de la existencia de deuda técnica en el software, además de ser capaz de evaluar cuándo debe pagarse para que el proyecto tenga un buen rendimiento en cuanto a mantenibilidad y escalabilidad.

Deuda Prudente e Inadvertida

En la Deuda Prudente e Inadvertida el desarrollador o desarrolladora utiliza buenas prácticas de programación, pero se da cuenta de que otro enfoque habría sido mejor para el desarrollo del producto. Por desgracia, este tipo de deuda suele descubrirse una vez terminado el proyecto desde un punto de vista prudente y deliberado.

¿Cómo reducir o minimizar la Deuda Técnica?

Una vez expuestas las cuatro tipologías de deuda técnica, creo que resulta bastante evidente que para reducirla podemos aplicar varias medidas:

Por un lado, los programadores Junior no deben estar solos en la ejecución de un proyecto, pues como indica su propio expertise, son más propensos a desconocer las buenas prácticas en programación y su poca experiencia puede llevar a un software poco mantenible y con fallas.

Por otro lado, la opción de decidir deliberadamente no hacer test unitarios, abstracciones y otras buenas prácticas puede ser un grave error que comprometa de forma importante el proyecto, y por tanto debe rechazarse.

Por último, es mejor tomar el control del software usando buenas prácticas y sabiendo cuales seleccionar en cada momento. De esta forma, esta decisión te ayudará a mantener a raya la Deuda Técnica consiguiendo así un equilibrio beneficioso entre tiempo y deuda.