Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Definición corta
Debilidad de diseño o de arquitectura de un software que la empresa ha decidido tratar, y que por ello lleva un coste de devolución y un lugar en las prioridades. Mientras esa decisión no se toma, la debilidad sigue siendo una incomodidad o un riesgo latente.
Definición detallada
En el uso corriente, la palabra abarca todo lo que un desarrollador lamenta en un código existente: un atajo antiguo, una arquitectura débil, una complejidad acumulada, una biblioteca obsoleta. La analogía financiera es ahí puramente descriptiva — se habla de deuda para decir que algo costará más adelante, sin que se nombre ningún acreedor, ningún vencimiento ni ningún importe.
En los artículos de este blog, la palabra se reserva a lo que ha pasado por una decisión. Una debilidad conocida desde hace años, que nadie ha inscrito en el programa, no es una deuda: no tiene fecha, ni coste arbitrado, ni responsable de la devolución. Lo pasa a ser cuando la empresa juzga que su coste de arrastre supera su coste de tratamiento — porque bloquea una estrategia, ralentiza mucho al equipo, expone a un riesgo, degrada la calidad percibida por el cliente o impide un cambio de producto importante.
El uso sobre el terreno diverge claramente del sentido elegido aquí: sobre el terreno, "tenemos deuda" designa un estado permanente del sistema, y no desencadena nada. El sentido elegido aquí hace de la palabra un estatus que se adquiere, no una constatación que se repite.
Uso en el ámbito
Revisión de priorización entre un tema de producto y un tema técnico, argumentación de un desarrollador ante un comité, decisión de entrada de un tema técnico en la roadmap, definición de una estrategia de tratamiento distinta de la gestión diaria de los bugs.
Sinónimos y variantes
"la deuda" en abreviado · "deuda de arquitectura" cuando la debilidad es estructural · "incomodidad técnica" y "riesgo latente" para el estado anterior a la decisión.
No confundir con
- Defecto — desviación entre el comportamiento esperado de un software y su comportamiento real; la deuda no tiene comportamiento defectuoso visible, cuesta en la evolución.
- Política cero bugs — régimen que prohíbe conservar un defecto conocido sin decisión; se refiere a las desviaciones de comportamiento, nunca a las debilidades de diseño.
- Roadmap — vista de los grandes temas comprometidos, preparados y posibles; la deuda técnica solo figura en ella después de la decisión de tratamiento.
- Deuda de comprensión — desviación entre lo que un equipo ha producido y lo que sabe de lo que ha producido; se paga en incapacidad para decidir qué rehacer, mientras que la deuda técnica se paga en trabajo de rediseño.
- Refactoring — gesto de mejora interna del código sin cambio de comportamiento; es un medio de devolución, no la deuda en sí.
- Complejidad esencial — dificultad inherente al problema tratado, que ningún trabajo de arquitectura elimina.
- Reconstruibilidad — propiedad de un sistema que un equipo sabría rehacer en otro sitio a partir de sus contratos, sus reglas de negocio y sus pruebas; califica lo que se sabe decir del sistema, no la calidad de su diseño.
- Deuda de comprensión — desviación entre lo que un sistema hace y lo que el equipo que responde de él sabe explicar; afecta a la cabeza de quienes mantienen, mientras que la deuda técnica afecta al estado del código, y no espera ninguna decisión para existir.
Ejemplos
Una arquitectura débil, conocida desde hace tiempo, que no impide a nadie entregar: incomodidad, no deuda.
La misma arquitectura, el día en que bloquea un trabajo estratégico y la empresa decide retomarla: deuda, con un lugar que encontrar en las prioridades.
Ambigüedades / debates
La analogía financiera está discutida: la deuda supone un préstamo voluntario, mientras que buena parte de lo que la palabra abarca se acumuló sin elección, por desconocimiento o por presión de plazos. Algunos proponen reservar su empleo a los atajos deliberados.
Segunda vacilación, más operativa: si hay que contar la deuda técnica en la capacidad del equipo o en los temas de la roadmap. Ambas respuestas circulan, y no comprometen al mismo árbitro.