¿Qué es la deuda técnica?
Cultura de ingeniería y práctica de software
La deuda técnica es una metáfora del coste futuro que se genera cuando el software es suficientemente fácil de entregar hoy, pero más difícil, lento o arriesgado de modificar después. El código sigue funcionando, y por eso la deuda resulta tentadora. El problema aparece en la siguiente funcionalidad, la siguiente corrección de errores o la siguiente migración, cuando el equipo invierte tiempo extra navegando por un diseño incómodo, pruebas frágiles, lógica duplicada o dependencias obsoletas.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa
Piénsese como tomar velocidad prestada del futuro. Un equipo toma un atajo, o simplemente construye con una comprensión parcial del problema, y consigue que algo funcione antes. Eso puede ser razonable. Pero el trabajo posterior cuesta más porque el software ya no encaja con la comprensión actual del equipo ni con la forma que ha tomado el producto.
La metáfora importa porque explica algo no evidente a quienes no son ingenieros. La calidad del código no es solo estética. Afecta a la velocidad con que un equipo puede responder, a la frecuencia con que los cambios salen mal y a cuánto empieza a parecer que el trabajo ordinario es caminar sobre cemento húmedo.
La deuda técnica es también un término paraguas. Un code smell suele ser la primera señal de alerta. El spaghetti code es una de las formas más evidentes en que la deuda puede manifestarse en el código fuente. Una big ball of mud es el aspecto que tiene el problema a escala de sistema. El bit rot se suma cuando las áreas descuidadas dejan de ejercitarse y se deterioran.
Por qué importa
Si se trabaja con ingenieros, la deuda técnica ayuda a explicar por qué solicitudes aparentemente sencillas pueden volverse costosas de repente. Una funcionalidad que suena pequeña en una reunión de planificación puede requerir una cirugía delicada si el código circundante es frágil, confuso o está atado a suposiciones antiguas. El equipo no está siendo quisquilloso. Está pagando intereses.
Por eso la deuda afecta a más que el estado de ánimo de los desarrolladores. Cambia la velocidad de entrega, la fiabilidad de las previsiones, el riesgo de incidentes, el tiempo de incorporación de nuevas personas y la moral del equipo. Con el tiempo, la organización empieza a sentirse más lenta sin saber siempre por qué. El trabajo se hace, pero con más cautela, más reelaboración y más sorpresas.
Para quienes lideran, el término es útil porque convierte una queja vaga sobre "código desordenado" en una compensación práctica. Asumir cierta deuda puede valer la pena. Parte de ella es simplemente mantenimiento descuidado. Lo importante es hacer visible el coste antes de que se convierta en el modelo operativo por defecto.
Cómo funciona
El origen del término
El término fue acuñado por Ward Cunningham en 1992 al describir cómo su equipo construyó el sistema financiero WyCash mediante un crecimiento incremental a partir de un prototipo funcional. Su argumento no era que los programadores debieran escribir código descuidado y prometer ordenarlo después. Era que, al construir de forma iterativa, la comprensión mejora sobre la marcha, por lo que el código anterior a menudo necesita revisarse para reflejar lo que se ha aprendido desde entonces.
Por eso la metáfora original tiene un lado sorprendentemente generoso. La deuda no es siempre un fracaso moral. A veces es el precio de aprender rápido. El problema comienza cuando el equipo sigue entregando sobre un código que ya no refleja lo que ahora sabe.
En qué consiste realmente la deuda
La deuda técnica no es una sola cosa. Puede manifestarse como reglas de negocio duplicadas, módulos que nadie puede modificar con seguridad, nombres confusos, pruebas frágiles, dependencias antiguas, suposiciones ocultas, scripts temporales convertidos en permanentes o un proceso de despliegue que solo una persona entiende. Ninguno de estos elementos es dramático por sí solo. Juntos, generan resistencia.
Los intereses de la deuda son el esfuerzo adicional que se añade al trabajo ordinario. Un cambio que debería llevar dos días lleva cinco. Una corrección de error pequeña necesita una semana de comprobaciones porque nadie confía en el área circundante. Una actualización de biblioteca provoca fallos no relacionados. Los ingenieros vuelven una y otra vez al mismo código confuso porque todas las funcionalidades pasan por él.
Amortizar el principal significa cambiar la estructura, no simplemente sobrevivir a ella. Eso puede implicar refactorizar, eliminar código obsoleto, dividir un módulo grande, mejorar las pruebas, reemplazar una interfaz antigua o consolidar reglas duplicadas en un único lugar claro.
Distintos tipos de deuda
Una forma útil de pensar en la deuda es hacerse dos preguntas. ¿Fue deliberada o inadvertida? ¿Y fue prudente o imprudente?
La deuda deliberada ocurre cuando un equipo elige conscientemente la velocidad ahora y el coste después. Puede ser razonable si la compensación es explícita, la ganancia es real y existe un plan creíble para revisarla. Por ejemplo, un equipo puede dar soporte primero a un flujo de trabajo de cliente concreto, sabiendo que el modelo deberá ampliarse tras el lanzamiento.
La deuda inadvertida es diferente. Aparece porque el desarrollo de software enseña cosas mientras se hace. Un año después de iniciar un producto, un equipo suele entender el dominio mejor que al principio. Incluso los buenos ingenieros pueden mirar atrás y ver código que tenía sentido entonces pero que ya no coincide con lo que saben ahora.
La deuda prudente tiene un propósito acotado. La deuda imprudente se asume de forma descuidada o se mantiene después de que su vida útil ha pasado. La metáfora funciona mejor cuando ayuda a un equipo a decidir con qué tipo está tratando, en lugar de tratar cada arista como idéntica.
Cómo se manifiesta en el trabajo real
La deuda tiende a acumularse en las áreas más activas. El código que cambia en cada sprint es donde llega primero la factura de intereses. Los equipos lo sienten como una creciente hesitación. Los ingenieros empiezan a advertirse mutuamente antes de tocar ciertos archivos. Las pull requests se alargan porque la gente añade comprobaciones defensivas. Los nuevos integrantes necesitan una visita guiada antes de poder hacer incluso un cambio modesto.
También aparece en los sistemas circundantes. Un equipo puede tener código de aplicación funcional pero un pipeline de construcción descuidado, un script de despliegue frágil o un proceso de cambio de base de datos que nadie quiere tocar. El producto puede parecer sano desde fuera mientras la deuda oculta hace que cada lanzamiento sea más angustioso de lo que debería.
Esta es una de las razones por las que el término trasciende la ingeniería. A un responsable de negocio puede no importarle si una clase es demasiado grande, pero sí le importa si cada nueva solicitud requiere trámites adicionales. La deuda técnica es el coste empresarial de la torpeza interna.
Cómo la amortizan los equipos en la práctica
Los equipos sanos rara vez eliminan la deuda con un rescate heroico. Con más frecuencia, la van reduciendo poco a poco mientras realizan el trabajo ordinario. Mejoran nombres al editar una función, eliminan código muerto cuando lo descubren, añaden una prueba antes de modificar un camino frágil o crean una separación alrededor de un área desordenada para que el trabajo posterior sea más seguro.
A veces se necesita un trabajo mayor. Una migración desde una API obsoleta, un rediseño de un modelo de precios o una revisión de la automatización del despliegue pueden requerir tiempo dedicado. Incluso entonces, los mejores esfuerzos suelen mantenerse acotados y con un propósito claro. Un equipo amortiza la deuda más rápido cuando apunta a una fuente específica de resistencia en un área importante, no cuando declara la guerra a todo el pasado.
Aquí es también donde importa la disciplina. Reducir deuda sin pruebas puede convertirse en otra forma de riesgo. Reducir deuda sin límites puede convertirse en yak shaving, con el equipo perdiéndose en limpiezas adyacentes y emergiendo muchos días después con un subsistema más ordenado y un plazo incumplido. El objetivo no es la limpieza por sí misma. El objetivo es facilitar el cambio.
Ejemplos
Un producto comienza en un país con reglas fiscales sencillas. Seis meses después sirve a varias regiones, cada una con distintas exenciones, reglas de redondeo y necesidades de informes. En lugar de revisar el modelo original, el equipo añade condición tras condición. El software sigue facturando correctamente a las personas, la mayor parte del tiempo, pero cada cambio de precios ahora requiere una comprobación cuidadosa en media docena de lugares. Esa comprobación adicional son los intereses.
Un equipo promete a un cliente clave un nuevo formato de exportación para finales de semana. Para cumplir el plazo, un ingeniero escribe una capa de traducción directa en el endpoint de la API en lugar de modelar la exportación correctamente. La compensación puede valer la pena si el formato de archivo aún es incierto y el código se revisa pronto. Si llegan tres clientes más y el camino rápido se convierte en el camino permanente, la deuda ha empezado a acumularse con interés compuesto.
Una organización hereda un sistema interno fiable que "simplemente funciona" y que, por eso, recibe poca atención. Con los años, la versión del entorno de ejecución, las bibliotecas, las herramientas de despliegue y las convenciones de nomenclatura evolucionan a su alrededor. La siguiente funcionalidad importante parece pequeña sobre el papel, pero nadie puede extender el sistema con seguridad sin modernizar antes grandes partes de él. Lo que parecía un problema de estimación de una funcionalidad es en realidad deuda que aflora de golpe.
Malentendidos frecuentes
La deuda técnica no es simplemente código antiguo. Parte del código antiguo es claro, estable, bien comprendido y barato de modificar. La antigüedad por sí sola no es el problema. El coste del cambio sí lo es.
La deuda técnica no es sinónimo de malos ingenieros. Los equipos excelentes también generan deuda porque el descubrimiento del producto cambia su comprensión con el tiempo. Los malos hábitos pueden empeorar la deuda, pero la deuda en sí no es prueba de incompetencia.
La deuda técnica no es solo un problema de código. Las pruebas, los pipelines de despliegue, las herramientas de construcción, los modelos de datos, la documentación y los acuerdos de responsabilidad pueden generar la misma resistencia futura.
La deuda técnica no es algo que una herramienta pueda medir completamente por sí sola. Las herramientas pueden detectar pistas útiles, especialmente APIs obsoletas, duplicación u otros code smells. No pueden ver del todo cuándo el código y la comprensión del equipo se han distanciado.
La deuda técnica no siempre necesita amortizarse por completo. Si el área afectada está inactiva, es estable y rara vez se toca, puede bastar con una contención parcial. La pregunta correcta es si la deuda está costando más que el trabajo necesario para reducirla.
Riesgos y límites
El término es fácil de usar en exceso. Si cada elección de estilo que no gusta se convierte en deuda técnica, la expresión pierde valor. Los equipos dejan entonces de distinguir entre resistencia real, compensaciones ordinarias y mera preferencia. Ahí es cuando la metáfora se convierte en papel pintado directivo.
La deuda también puede convertirse en una coartada. "Sabemos que es deuda" no es una estrategia. Si nadie es responsable de la decisión, no existe una fecha de revisión y ningún trabajo futuro tiene en cuenta el coste, la organización no está gestionando la deuda. Simplemente está conviviendo con el deterioro.
El uso más saludable del término es preciso y modesto. Nombrar el área, describir la resistencia, explicar el coste de dejarla y decidir si este es el momento de actuar.
Qué hacer a continuación
En primer lugar, pedir especificidad. No conviene aceptar "hay mucha deuda técnica" como una afirmación útil. Hay que preguntar qué parte del sistema está ralentizando el trabajo, qué tipo de esfuerzo adicional genera y con qué frecuencia el equipo tiene que pagar ese precio.
En segundo lugar, hacer visible la deuda en las mismas conversaciones de planificación que el trabajo de funcionalidades. Si un equipo necesita simplificar un camino crítico antes de añadir una capacidad importante, conviene tratarlo como parte de la entrega, no como trabajo secundario que se encaja a base de buena voluntad.
En tercer lugar, recompensar las reparaciones continuas y pequeñas. Los equipos que deben entregar de forma continua necesitan permiso para refactorizar de forma continua. Las eliminaciones, las mejoras de pruebas, las actualizaciones de dependencias y las limpiezas de interfaces deben contar como progreso real, porque son lo que evita que el trabajo futuro se paralice.
Por último, hay que estar atentos a las señales sociales. Cuando los ingenieros evitan ciertos archivos, cuando las estimaciones llevan una prima de miedo oculta o cuando solo una persona puede modificar un flujo de trabajo central, la deuda ya está dando forma a la organización.
¿Tiene alguna pregunta o sugerencia, o quiere entender cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es la deuda técnica simplemente otro nombre para el código desordenado?
No. El código desordenado puede ser parte de ella, pero la idea central es el coste futuro. Si el diseño de hoy hace más difícil el cambio de mañana, hay deuda tanto si el código parece feo como si no.
¿En qué se diferencia la deuda técnica de un code smell?
Un code smell es una pista. La deuda técnica es el panorama de costes más amplio. Un smell puede apuntar a deuda, pero no es el balance completo.
¿Puede una startup ignorar la deuda técnica?
Una startup puede asumir más deuda que un banco o un sistema hospitalario, pero tampoco puede ignorarla indefinidamente. Las startups viven de la velocidad, y la deuda impagada acaba atacando la velocidad primero.
¿Significa la deuda técnica que hay que reescribir todo?
Generalmente no. Las reescrituras completas descartan el conocimiento funcional junto con la estructura incómoda. La mayor parte de la deuda se gestiona mejor mediante refactorización selectiva, eliminación y migración.
¿Quién debe ser responsable de la deuda técnica?
El equipo que realiza el trabajo debe ser responsable de la deuda local, mientras que el liderazgo hace visibles y financiables las compensaciones. La responsabilidad sin planificación no es suficiente, y la planificación sin responsabilidad es teatro.
¿Cómo se explica la deuda técnica a quienes no son ingenieros?
Describir los intereses. Decir qué lleva más tiempo, qué falla con más frecuencia o qué requiere conocimientos especializados poco comunes. Una vez que la resistencia es visible, la metáfora suele tener sentido muy rápidamente.