Deuda técnica: qué es, cómo se nota y cómo se paga
La deuda técnica es el coste futuro de los atajos al programar: un poco acelera, pero la que no se paga encarece cada cambio. Se controla con pruebas automáticas, cambios pequeños y reversibles, actualizaciones a tiempo y tiempo reservado en el mantenimiento.
La deuda técnica es el coste futuro de los atajos que se toman al programar: cada solución rápida que no se ordena después hace que el siguiente cambio cueste más. Como una deuda financiera, un poco puede ser útil para llegar antes; la que no se paga genera intereses en forma de cambios cada vez más lentos, errores que aparecen donde no se tocó nada y un programa que solo entiende una persona.
De dónde viene la expresión
La metáfora la propuso Ward Cunningham en un informe de experiencia sobre un sistema de gestión de carteras financieras, presentado en la conferencia OOPSLA de 1992. Su idea era sencilla: entregar código en su primera versión, sin consolidar, es como endeudarse; un poco de deuda acelera el desarrollo siempre que se devuelva pronto reescribiendo, y el peligro aparece cuando no se devuelve, porque cada minuto dedicado a código que no está del todo bien cuenta como interés de esa deuda.
Lo útil de la metáfora es que traslada un problema técnico a un lenguaje que entiende cualquier gerente: no se trata de que el código sea bonito, sino de cuánto cuesta cambiarlo mañana.
Cómo se nota la deuda técnica sin ser técnico
- Los cambios pequeños tardan cada vez más. Lo que hace un año era una tarde, ahora es una semana.
- Arreglar algo rompe otra cosa que aparentemente no tenía relación.
- Hay partes que nadie quiere tocar o que solo sabe tocar una persona.
- Da miedo actualizar: el servidor, las librerías o el propio programa llevan tiempo sin ponerse al día.
- Los errores los descubren los usuarios, porque no hay pruebas automáticas que los detecten antes.
- Cada presupuesto de mejora incluye «rehacer primero» una parte que no se había pedido.
Tipos de deuda técnica
No toda la deuda es igual, y no toda es un error:
- Deliberada: se toma un atajo a sabiendas, por ejemplo en una primera versión, con el plan de ordenarlo después. Es legítima si ese después llega. Lo contamos en MVP en desarrollo de software.
- Accidental: se hizo lo mejor que se sabía, y con el tiempo se entiende que había una forma mejor.
- De dependencias: librerías, lenguajes o servidores que se quedan sin actualizar hasta que dejan de tener soporte.
- De pruebas: no hay comprobaciones automáticas, así que cada cambio se prueba a mano, o no se prueba.
- De datos: duplicados, campos que significan cosas distintas según quién los rellenó, estructuras que ya no reflejan el negocio.
- De conocimiento: decisiones que no están escritas en ningún sitio y se van con quien las tomó.
Cómo se controla la deuda técnica
La deuda técnica no se elimina: se gestiona, igual que una financiera. Lo que funciona es hacerla visible y pagar un poco en cada ciclo, en lugar de esperar a que obligue a parar. Tres prácticas que aplicamos en los sistemas que mantenemos:
- Pruebas automáticas. Antes de publicar un cambio pasan más de mil comprobaciones automáticas. Son la red que permite ordenar código sin miedo a romper lo que ya funciona.
- Cambios pequeños y reversibles. Copia de seguridad antes de cualquier cambio en la base de datos, con migraciones pequeñas y reversibles.
- Comprobar que la versión nueva arranca de verdad antes de sustituir la que está en marcha: que la vieja responda no prueba que la nueva funcione.
Y dos que conviene exigir siempre, las haga quien las haga:
- Actualizar a tiempo las dependencias, antes de que el salto sea demasiado grande.
- Escribir las decisiones, sobre todo los atajos: qué se hizo, por qué y cuándo hay que revisarlo.
En el lenguaje de los contratos, pagar deuda técnica es sobre todo mantenimiento preventivo y perfectivo. Qué incluye cada tipo lo explicamos en tipos de mantenimiento de software.
Qué pedir a tu proveedor
- Pruebas automáticas en cada entrega, y que te enseñe que se ejecutan.
- Una lista de atajos conocidos: qué deuda se ha tomado a propósito y cuándo se pagará.
- Un plan de actualizaciones de las piezas de las que depende tu sistema.
- Tiempo reservado en el mantenimiento para ordenar, no solo para corregir y añadir.
- Documentación suficiente para que otra persona pueda continuar el trabajo. Qué debe decir el contrato sobre esto está en contrato de mantenimiento de software.
Cuándo compensa rehacer en lugar de pagar poco a poco
Cuando los intereses se comen todo el presupuesto de mejoras, cuando la tecnología de base ya no tiene soporte o cuando el negocio ha cambiado tanto que la estructura del programa no lo refleja. Aun así, rehacer de golpe suele ser la opción más arriesgada; muchas veces conviene modernizar por partes, con el sistema antiguo funcionando mientras tanto. Las opciones, con una tabla para decidir, están en qué hacer con el software legacy.
Fuentes consultadas
Comprobadas el 27 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- The WyCash Portfolio Management System, OOPSLA '92 Experience Report. Ward Cunningham (texto original del autor en c2.com).
Preguntas frecuentes
¿Toda la deuda técnica es mala?
No. Tomar un atajo a sabiendas para llegar antes puede ser una buena decisión, como pedir un préstamo. El problema es la deuda que nadie apunta ni planifica pagar, porque sus intereses encarecen cada cambio.
¿Cómo se mide la deuda técnica?
No hay una cifra única. Las señales más útiles para una empresa son cuánto tarda un cambio pequeño, cuántos errores aparecen tras cada entrega y cuántas partes del sistema solo sabe tocar una persona.
¿La deuda técnica es culpa del programador?
Rara vez solo suya. Suele venir de plazos apretados, requisitos que cambian y mantenimiento que solo corrige y añade. Por eso se gestiona entre la empresa y el proveedor, con tiempo reservado para ordenar.
¿Se puede evitar del todo?
No: cualquier sistema vivo acumula algo de deuda, porque el negocio y la tecnología cambian. Lo que se puede es mantenerla baja y visible, con pruebas automáticas y cambios pequeños.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.