¿Qué es la deuda técnica y por qué se acumula más rápido cuando cambia el equipo?

La deuda técnica es el costo futuro que se paga por elegir hoy la solución rápida en vez de la más prolija: cada atajo queda pendiente como un préstamo, con interés que se cobra en bugs, en funcionalidades que cuestan cada vez más construir y en código que nadie quiere tocar. No es sinónimo de código malo —es una decisión, consciente o no, de posponer un trabajo para más adelante. El problema real no es que exista: es no saber cuánta hay acumulada, ni quién se va a hacer cargo de pagarla.

Todo proyecto de software genera algo de deuda técnica —no es evitable ni siempre es un error. Lo que decide si se vuelve un problema es si alguien la registra y la paga a propósito, o si se acumula en silencio hasta que el sistema se vuelve más caro de cambiar que de tirar y volver a hacer.

¿De dónde viene el término y qué significa realmente “pagarla”?

La metáfora la acuñó el programador Ward Cunningham en 1992, en un reporte sobre el desarrollo de un sistema financiero: comparó escribir código de la forma más rápida posible con pedir un préstamo. Ese préstamo te deja avanzar más rápido en el corto plazo, pero cada ciclo que pasa sin refactorizar ese código suma interés —el sistema se vuelve más rígido, más lento de modificar y más caro de entender para alguien que no lo escribió. “Pagarla” significa dedicar tiempo de desarrollo a reescribir, documentar o simplificar ese código, en vez de seguir construyendo funcionalidad nueva encima.

¿Cuánto tiempo y presupuesto se va realmente en pagarla?

El dato de referencia más citado en la industria es de Stripe: en su encuesta a más de 1.000 desarrolladores y 1.000 ejecutivos de nivel C en cinco países, los equipos de ingeniería reportaron dedicar en promedio 17,3 horas semanales —42% de la semana laboral relevada— a mantenimiento y código mal escrito, en vez de construir funcionalidad nueva (Stripe, The Developer Coefficient, 2018). El 79% de los ejecutivos consultados dijo que el tiempo perdido en sistemas legacy era una preocupación significativa para el negocio.

McKinsey encuestó a 50 CIOs de grandes empresas de servicios financieros y tecnología y encontró que, en promedio, la deuda técnica representa entre el 20% y el 40% del valor de todo el estado tecnológico de una empresa —y que entre el 10% y el 20% del presupuesto reservado para construir producto nuevo termina destinado a resolver problemas heredados (McKinsey, Tech debt: Reclaiming tech equity, 2020). El Global Technology Leadership Study más reciente de Deloitte ubica ese arrastre en un rango similar: entre 21% y 40% del gasto total en tecnología de una organización (Deloitte, Global Technology Leadership Study, 2026).

¿Por qué se acumula más rápido cuando cambia el equipo que escribió el código?

El código no documenta las razones detrás de cada decisión —eso vive en la memoria de quien lo escribió. Cuando ese equipo cambia a mitad de proyecto, esa razón se pierde con él: el próximo equipo hereda el resultado sin el contexto, y ante la duda, casi nadie refactoriza código ajeno que no entiende del todo —lo rodea con más código nuevo, hasta que tocar esa zona del sistema da miedo. Eso es exactamente lo que acelera la acumulación: no es que un equipo nuevo escriba peor, es que cada traspaso resetea el conocimiento tácito que evitaba que la deuda creciera sin control.

Es la misma razón por la que un squad que ya trabajó junto en otros proyectos —y sigue siendo el mismo equipo de principio a fin— acumula menos deuda invisible que uno que se arma de cero para cada contrato: no porque las personas sean mejores, sino porque el conocimiento sobre por qué el sistema se construyó de una forma específica no se pierde en el camino.

¿Toda deuda técnica es mala?

No. El propio Martin Fowler, en 2009, propuso pensarla en dos ejes: si fue una decisión deliberada o inadvertida, y si fue una decisión prudente o imprudente (Martin Fowler, Technical Debt Quadrant, 2009). Tomar un atajo consciente para validar una hipótesis de negocio rápido —sabiendo que hay que volver a esa parte del código después— es deuda prudente y deliberada. El problema no es tomar ese atajo: es no anotarlo en ningún lado y descubrirlo meses después, cuando ya nadie recuerda que era temporal.

¿Cómo se evita que se acumule sin frenar la velocidad de entrega?

La forma más efectiva de no acumular deuda invisible no es frenar y refactorizar todo antes de seguir —es que cada entrega quede documentada con criterios explícitos desde el momento en que se define, y que el trabajo pase por una revisión antes de sumarse al resto del sistema. En Zenit, cada milestone se acuerda con criterios de aceptación firmados de antemano, así que “terminado” no es una palabra ambigua que cada quien interpreta distinto seis meses después.

Kaizen suma otra capa durante la ejecución: no solo arma el match inicial, acompaña el proyecto milestone a milestone y vuelve a la empresa si detecta una señal de riesgo real —antes de que se convierta en el tipo de atajo silencioso que nadie documentó.

La visibilidad también importa: si la evidencia de avance es el código mismo —commits, pull requests, code review— en vez de un reporte verbal, la deuda que se está acumulando queda a la vista de la empresa, no escondida detrás de un “va todo bien” en la reunión semanal.

La deuda técnica no se elimina —ningún proyecto de software llega a cero. Lo que cambia el resultado es si alguien sabe cuánta hay, quién la generó y cuándo se planea pagarla, en vez de descubrirla recién cuando el sistema ya es demasiado caro de tocar.