Cuando hacemos una mudanza con prisa, a veces metemos las cosas en las cajas de cualquier manera y decidimos ordenarlas más adelante. Así terminamos antes, pero en la casa nueva tenemos que rebuscar en varias cajas para encontrar un solo objeto, y cuanto más aplazamos el orden, más trabajo nos cuesta. En el desarrollo de software ocurre exactamente lo mismo, y el término que lo describe es «deuda técnica (Technical Debt)».
En pocas palabras, la deuda técnica es el coste adicional de corregir y pulir más adelante lo que se hizo de la forma más fácil para avanzar rápido en vez de optar por un diseño mejor. El programador estadounidense Ward Cunningham empleó por primera vez esta metáfora en una presentación en un congreso en 1992. Hoy es un término habitual tanto entre los desarrolladores como entre los directivos y los responsables de planificación.
Este artículo explica de forma sencilla qué es la deuda técnica y cómo surgió el concepto, cómo se acumula, qué tipos de deuda existen y cómo gestionarla y pagarla poco a poco.
Cómo funciona la deuda técnica y cómo gestionarla
¿Qué es la deuda técnica?
Cunningham presentó esta metáfora en 1992 en OOPSLA, un congreso sobre programación orientada a objetos, al hablar de su experiencia desarrollando un programa financiero. Dijo que publicar la primera versión del código equivale a contraer una deuda. Endeudarse un poco acelera el desarrollo, pero esa deuda debe pagarse a tiempo reescribiendo el código.
La metáfora se difundió porque se entiende enseguida, incluso sin dedicarse al desarrollo. Así como una deuda genera intereses, cuando se deja tal cual un código escrito a la ligera, cada función que se añade sobre él exige un poco más de tiempo y esfuerzo. Cunningham advirtió que, si se acumulan las deudas pendientes de pago, el peso de los intereses puede llegar a paralizar a toda la organización.
Aquí, el principal es el propio código deficiente que aún queda por corregir, y el interés es el tiempo y el esfuerzo adicionales que ese código exige una y otra vez. Pagar el principal significa reestructurar bien el código. Mientras quede principal pendiente, se seguirán acumulando intereses conforme avance el desarrollo.
¿Cómo se acumula la deuda y cómo se generan los intereses?
La deuda técnica se acumula de varias maneras. Algunos ejemplos típicos son saltarse las pruebas para cumplir la fecha de lanzamiento, copiar y pegar código similar sin modificarlo o dejar el código sin documentar. También puede surgir sin que nadie haya cometido un error, por ejemplo, cuando un diseño que al principio era adecuado deja de serlo a medida que crece el servicio.
Los intereses se acumulan de formas difíciles de ver. Basta con modificar una función pequeña para que aparezcan errores en lugares inesperados, y un desarrollador recién incorporado puede pasar semanas tratando de entender un código enrevesado. El tiempo necesario para realizar la misma tarea aumenta poco a poco cada año, pero el cambio de un día a otro es tan pequeño que cuesta advertirlo.
Lo peligroso de estos intereses es que crecen como el interés compuesto. Cuando se añade código nuevo sobre código escrito a la ligera, el nuevo código también tiene que amoldarse a esa estructura deficiente. Al final, un atajo en un punto obliga a dar rodeos en varios más, y lo que hay que corregir acaba siendo varias veces más extenso que al principio.
Cuando los intereses superan al principal, se llega a dedicar más tiempo a contener los problemas existentes que a desarrollar nuevas funciones.
Tipos de deuda técnica y por qué no toda deuda es mala
En 2009, el desarrollador de software británico Martin Fowler presentó el «cuadrante de la deuda técnica», que la clasifica según dos criterios. El primero distingue si la deuda se contrajo de forma deliberada o inadvertida, y el segundo, si se actuó con prudencia o con imprudencia.
(1) Deuda prudente y deliberada
Es una deuda que se asume conociendo las consecuencias. Por ejemplo, «Ahora lo primero es lanzar el producto. Hagámoslo así y ya lo corregiremos». Puede ser una decisión estratégica que permita aprovechar una oportunidad crucial para el negocio.
(2) Deuda imprudente y deliberada
Se da cuando se hace el trabajo a la ligera a sabiendas, con el argumento de que «no hay tiempo para diseñar». Es la forma más peligrosa.
(3) Deuda contraída de forma inadvertida
Es la deuda que surge por falta de experiencia o cuando, solo después de terminar el trabajo, uno se da cuenta y piensa «Así era como debía haberlo hecho». También es difícil evitarla durante el aprendizaje.
Incluso una deuda deliberada se vuelve imprudente enseguida si no hay un plan para pagarla. En el trabajo de desarrollo es muy habitual que el código que se iba a «corregir más adelante» siga igual años después.
Por eso, la deuda técnica se gestiona como un préstamo bancario. En vez de evitarla a toda costa, hay que evaluar cuándo conviene contraerla, cuánta asumir y cómo pagarla.
Cómo gestionar y pagar la deuda técnica
La forma más habitual de pagar la deuda es la refactorización (Refactoring). Consiste en mejorar la estructura del código para que sea más fácil de leer y modificar, manteniendo el comportamiento del programa. Como los resultados son difíciles de apreciar desde fuera, lo más importante es que tanto los desarrolladores como los directivos entiendan el coste de la deuda.
(1) Registrar la deuda
Anotar en la lista de tareas las partes que se corregirán más adelante evita que se olviden y permite ver de un vistazo cuánta deuda se ha acumulado.
(2) Pagar la deuda poco a poco y con constancia
Reservar una parte del tiempo de desarrollo para ir corrigiendo un poco cada vez puede evitar que los intereses sigan creciendo.
(3) Crear una red de seguridad con pruebas
Contar con pruebas automatizadas permite comprobar enseguida si un cambio en el código ha provocado fallos en otras partes, lo que facilita el pago de la deuda.
(4) Reconstruir el sistema cuando la deuda es demasiado grande
Si la deuda se ha acumulado hasta el punto de que corregir el sistema cuesta más que crear uno nuevo, una opción es sustituir el sistema antiguo por uno nuevo de forma gradual. Dado que el coste y el riesgo son elevados, la decisión debe tomarse con prudencia.
La deuda técnica recurre a la idea familiar de la deuda para ilustrar una realidad del desarrollo de software, donde siempre hay que buscar un equilibrio entre velocidad y calidad. Olvidar que se ha contraído una deuda es un problema mayor que contraerla, y una deuda bien gestionada puede incluso facilitar un crecimiento rápido.
Recordar que el tiempo ahorrado hoy se pagará mañana en forma de intereses es el primer paso hacia un software sano.
