Deuda técnica: qué es y cómo eliminarla.

La deuda técnica es probablemente el concepto peor entendido y peor gestionado del desarrollo de software en empresas españolas. La analogía financiera original de Ward Cunningham es precisa: igual que una deuda monetaria genera intereses que acaban superando el principal si no se paga, una deuda técnica genera «intereses» en forma de velocidad de desarrollo reducida, bugs que aparecen en módulos aparentemente no relacionados, pérdida de talento (los buenos ingenieros no aguantan meses peleando con código mal mantenido) y cada vez mayor coste de añadir cualquier funcionalidad. La deuda técnica no se ve en los comités de dirección hasta que es tardísima: de repente, un cambio que debería tomar dos días toma dos semanas, los despidos por estrés del equipo se disparan y la única opción que parece quedar es reescribirlo todo —la opción más cara y arriesgada, la que casi nunca termina bien.

Las señales reconocibles de una deuda técnica acumulada que ya está costando dinero son específicas: añadir cualquier funcionalidad simple toma más tiempo del esperado (el equipo se pelea con el código en lugar de escribirlo); los bugs aparecen en módulos que no se han tocado al hacer un cambio aparentemente aislado (acoplamiento excesivo); el código no tiene tests o los tests existentes están rotos y todos los ignoran; hay módulos del código que nadie del equipo quiere tocar por miedo a romper algo; los developers nuevos tardan semanas o meses en ser productivos porque la arquitectura no es comprensible; las dependencias están desactualizadas y hay miedo a actualizarlas; el deployment es manual o semi-manual y se evita porque asusta; el equipo habla mucho de «legacy» y poco de producto; y las estimaciones son crónicamente optimistas porque nadie sabe realmente qué se tardará en hacer cualquier cosa.

La solución a la deuda técnica casi nunca es una reescritura completa. El famoso «second system effect» de Fred Brooks documenta por qué: los equipos que se ponen a rehacer desde cero subestiman sistemáticamente el esfuerzo, pierden features implícitas del código original (bugs útiles o comportamientos de edge case que el negocio dependía sin saberlo) y acaban con un sistema nuevo que tiene su propia deuda técnica distinta. La aproximación correcta es refactoring incremental: hacer una auditoría técnica que cuantifique la deuda en semanas-hombre de trabajo, priorizar por impacto en la velocidad del equipo y el riesgo de producción, y dedicar un porcentaje fijo de cada sprint (típicamente 20%) a reducir deuda mientras se sigue entregando funcionalidades nuevas. Esta aproximación es sostenible, mantiene el producto en producción y suele eliminar el 80% de los problemas en 4-6 meses sin parar el negocio.

Los casos donde sí tiene sentido una reescritura parcial son concretos: cuando el stack tecnológico base ya no tiene soporte (Flash, Cordova antiguo, Angular 1); cuando la arquitectura fundamental es incorrecta para el caso de uso actual (monolito que debería ser event-driven, base de datos no escalable, modelo de datos roto); cuando el coste de mantener lo actual supera claramente el de reconstruir. Incluso en estos casos, se prefiere una migración por módulos (siguiendo el patrón Strangler Fig de Martin Fowler) que reemplaza piezas gradualmente sin interrumpir el producto. Dribba realiza auditorías de deuda técnica para productos en producción (3.000-10.000€, 2-3 semanas) que entregan diagnóstico cuantificado y plan de remediación priorizado. La remediación misma suele ejecutarse en paralelo al desarrollo de producto con dedicación parcial del equipo, y suele recuperar velocidad del equipo interno en 3-6 meses. Si sientes que tu equipo «va cada vez más lento sin razón aparente» y las decisiones técnicas son cada vez más difíciles de tomar, la deuda técnica probablemente es la causa y una auditoría externa es la forma más barata de confirmarlo.