![Imagen de portada de [Code Smell #6] Deuda técnica: el significado original de Cunningham](/assets/images/posts/1e489696-56aa-4ba2-b569-5cdc8f77c60e/technical-debt-compound-interest-typeset-v1.jpg)
Respuesta clave: la deuda técnica es un término acuñado por Ward Cunningham en 1992. Originalmente significaba la brecha entre el código y la comprensión actual, no el código desordenado.
Cunningham recalcó que una estrategia de deuda solo funciona cuando el código es limpio.
Hay un término que los desarrolladores usan al explicar la refactorización a personas no técnicas: deuda técnica.
Este artículo continúa el anterior, Code Smell #5.
La idea es que nos endeudamos para construir algo rápido, se acumulan intereses y necesitamos tiempo para pagarlos.
Sin embargo, su creador explicó varias veces que la metáfora se estaba usando mal, especialmente al llamar deuda al código desordenado.
Ward Cunningham, 1992
Ward Cunningham utilizó por primera vez la expresión deuda técnica en 1992, en un informe de experiencia para OOPSLA (Object-Oriented Programming, Systems, Languages & Applications, la conferencia de programación orientada a objetos) (Artículo).
Es el mismo Cunningham conocido por inventar la wiki y por ser una figura temprana de la programación extrema.
En aquel momento desarrollaba software financiero. La dificultad estaba en el dominio.
No se puede comprender con precisión la estructura de los productos financieros antes de empezar. Por eso eligió construir y publicar lo que entendía en ese momento, e incorporar continuamente al código lo aprendido durante el uso.
La deuda de la que hablaba surge aquí: la diferencia entre la comprensión que contiene el código actual y la comprensión que el equipo realmente tiene ahora.
Una estructura correcta al principio puede dejar de encajar cuando se conoce mejor el dominio. Eso es deuda; adaptar el código a la nueva comprensión es el pago.
En 2009 dejó un breve vídeo para volver a explicar la metáfora y corregir el malentendido. La idea era esta (Debt Metaphor).
Contraer deuda es una estrategia para aprender rápido, no un permiso para escribir código deficiente. De hecho, la estrategia solo funciona si el código es limpio.
Si está desordenado, incorporar lo aprendido se vuelve imposible.
Este es el punto central: en el concepto original, la deuda también aparece en código bien escrito.
Surge automáticamente cuando cambia nuestra forma de entender el mundo con el paso del tiempo.
En cambio, gran parte de lo que hoy llamamos deuda técnica es simplemente código escrito a la ligera. Según Cunningham, eso se parece más a un desastre que a una deuda.
El cuadrante de Fowler
Aun así, establecer que «solo la deuda real es deuda» dificulta su uso práctico. El cuadrante que Martin Fowler resumió en 2009 cubre bien esa brecha (Technical Debt Quadrant).
Usa dos ejes: intencional frente a inadvertida, e imprudente frente a prudente.
| Imprudente | Prudente | |
|---|---|---|
| Intencional | «No hay tiempo para diseñar» | «Lanzamos ahora y asumimos el coste» |
| Inadvertida | «¿Qué es la separación de capas?» | «Ahora entiendo cómo debería haberse hecho» |
Las cuatro celdas tienen características completamente distintas.
Intencional·prudente es una decisión de negocio. Hay una fecha límite, retrasarse implica perder una oportunidad y se elige sabiendo que el coste llegará después.
Es la celda en la que la metáfora de la deuda encaja con mayor precisión.
Hay una condición: conocer el coste.
Inadvertida·prudente es la deuda original de Cunningham. Se hizo el mejor trabajo posible y, seis meses después, al entender mejor el dominio, aparece una estructura mejor.
Surge aunque nadie haya hecho nada mal. Como no puede evitarse, la única respuesta es establecer un ciclo de pago.
Intencional·imprudente significa actuar de forma descuidada a sabiendas. Suele llamarse deuda, pero sin un plan de pago se parece más a una pérdida.
Inadvertida·imprudente significa que ocurrió por falta de conocimiento. La solución aquí es aprender, no programar una refactorización.
La respuesta al mismo código desordenado cambia según la celda. Cuando los equipos hablan de deuda y no se entienden, a menudo es porque imaginan celdas distintas.
¿Con qué se pagan los intereses?
El interés de la deuda financiera es dinero; el de la deuda técnica es el coste de los cambios futuros. Si añadir la misma función tarda un día sin deuda y tres días con ella, los dos días extra son intereses.
Esta definición lleva a una conclusión: la deuda del código que nadie toca tiene un interés de cero.
Aunque un módulo que nadie modifica desde hace cinco años esté muy desordenado, si tampoco se modificará en el futuro no hay razón para pagarlo. En cambio, una pequeña deuda en una pantalla que se toca cada semana sigue generando intereses.
Muchos equipos ordenan la lista por «cuánto de mala es», pero el criterio real debería ser «con qué frecuencia se toca».
La consulta de frecuencia de cambios de Git del artículo anterior también sirve aquí. La intersección entre archivos que cambian con frecuencia y archivos de baja calidad es donde el tipo de interés es más alto.
Adam Tornhill llama análisis de código basado en el comportamiento al enfoque de encontrar esa intersección y priorizarla.
Los límites de la metáfora
La expresión deuda técnica es cómoda, y ese es precisamente el problema. Se puede incluir cualquier cosa.
Bugs, bibliotecas antiguas, diseños que no gustan y código que no escribiste: todo se llama deuda. Entonces la palabra se convierte en sinónimo de «cosas que quiero arreglar» y pierde su capacidad explicativa original.
Solo es práctico llamarlo deuda cuando supera dos preguntas.
- **¿Qué obtuviste al contraerla?**Debes poder decir si ganaste tiempo o aprendizaje. Si no obtuviste nada, no es deuda sino un error.
- **¿Cómo la pagarás?**Una deuda sin plan de pago no sostiene la metáfora.
También hay quienes rechazan la metáfora. La palabra deuda sugiere que «algún día se pagará», ocultando situaciones en las que crece con interés compuesto hasta resultar imposible de saldar.
Algunos proponen llamarlo contaminación o un problema de higiene, porque se parece más a algo que hay que limpiar continuamente que a algo que se paga.
Aun así, la palabra deuda ha sobrevivido tanto tiempo por una razón: es una de las pocas metáforas que permiten hablar con personas ajenas al desarrollo.
Cunningham utilizó la metáfora por primera vez al explicar a su jefe la necesidad de rehacer trabajo. No es un término preciso, pero sigue siendo útil como herramienta de traducción.
Cómo gestionarla en la práctica
**Haz una lista, pero no la entierres en el gestor de incidencias.**Un backlog compuesto solo por tickets de deuda normalmente no lo mira nadie.
En su lugar, deja la información cerca del código. Si anotas brevemente en el archivo por qué quedó así y qué necesita, la verá quien lo abra después.
**Págala mientras estás ahí.**Cuando de todos modos vas a modificar el archivo, se generan intereses y el contexto sigue presente.
Por eso la regla del boy scout, «déjalo más limpio de como lo encontraste», funciona realmente como método para gestionar la deuda.
**Decidir no pagarla también es gestionarla.**La mitad de la lista de deuda es para registrar, no para pagar.
Decidir explícitamente no pagar un elemento evita repetir la misma discusión más adelante.
**Cuando contraigas deuda intencionalmente, anota también la condición.**Por ejemplo, «en las dos semanas posteriores al lanzamiento» o «antes de superar los 10.000 usuarios».
Una deuda contraída sin fecha tampoco tiene fecha de pago.
Resumen
- La deuda técnica es un término acuñado por Ward Cunningham en 1992. Originalmente significaba la brecha entre el código y la comprensión actual, no el código desordenado.
- Cunningham recalcó que una estrategia de deuda solo funciona cuando el código es limpio.
- El cuadrante de Fowler divide las celdas según la intencionalidad y la prudencia. Cada una requiere una respuesta distinta.
- El interés es el coste de los cambios futuros. La deuda del código que no se toca tiene interés cero, así que no hay razón para pagarla.
- Si no puedes explicar qué obtuviste ni cómo la pagarás, no es deuda sino simplemente un problema.
El próximo artículo trata las opciones cuando la deuda se acumula hasta volverse inmanejable: arreglarla para seguir usándola o reescribirla.
También es el lugar donde han surgido algunas de las respuestas incorrectas más caras de la industria del software.
Fuentes y criterios de verificación
- The WyCash Portfolio Management System — Ward Cunningham · Artículo original · Verificado 2026-08-17 · Base: explicación original de la metáfora de la deuda técnica de 1992
- Debt Metaphor — Ward Cunningham · Texto original del autor · Verificado 2026-08-17 · Base: explicación de Ward Cunningham de 2009 sobre la metáfora de la deuda técnica
- Technical Debt Quadrant — Martin Fowler · Texto original del autor · Verificado 2026-08-17 · Base: cuadrante de deuda técnica dividido por prudencia, imprudencia e intencionalidad
Seguir leyendo
Serie Code Smell
- Artículo anterior: [Code Smell #5] Cirugía a escopetazos frente a cambio divergente
- Artículo anterior: [Code Smell #4] God Object: guía completa
- Artículo anterior: [Code Smell #3] Código ravioli: código cuyo flujo nadie entiende