Deuda Técnica: Qué Es de Verdad, Cuándo es Buena y Cómo se Paga

«Tenemos mucha deuda técnica» es una de las frases más pronunciadas y menos entendidas del sector. Los desarrolladores la usan para decir «este código me duele». Los gestores la escuchan como «quiero tiempo para cosas que no se venden». Y entre ambas lecturas, la deuda técnica se convierte en un concepto inútil: todo es deuda, nada es prioritario, y la conversación siempre acaba en «ya hablaremos de eso».

La metáfora original de Ward Cunningham era mucho más precisa — y más útil: la deuda técnica es pedir prestada velocidad al futuro. Como toda deuda, puede ser una palanca brillante o una trampa mortal. La diferencia no está en cuánta tienes, sino en si sabes cuánta tienes, por qué la contrajiste y cómo se paga. Esta guía pone eso en orden, para ingenieros y para negocio.

Qué Es la Deuda Técnica (de Verdad)

La deuda técnica es la distancia entre el código que tienes y el código que necesitarías para que el siguiente cambio fuera barato. No es «código feo»: es código cuya estructura actual hace que cada cambio cueste más de lo que debería.

La metáfora financiera funciona porque encaja en tres detalles que la mayoría olvida:

1. Se contrae por algo. Nadie pide una hipoteca por aburrimiento: la pides porque comprar casa a tocateja es imposible. La deuda técnica se contrae para lanzar antes, validar un mercado, cumplir un contrato. El préstamo tiene un propósito — y si no lo tenía, no era deuda: era descuido.
2. Genera intereses. Cada feature nueva sobre un código mal estructurado cuesta un poco más que la anterior. Los intereses no se ven en ninguna factura: se ven en la velocidad del equipo, que decae mes a mes sin que nadie sepa explicar por qué.
3. Se amortiza o te come. Una deuda sin pagos crece. El código no mejora solo con el tiempo; empeora, porque cada cambio apresurado suma más distancia.

Los Cuatro Tipos (No Toda la Deuda es Igual)

El cuadrante clásico de Martin Fowler separa la deuda por dos ejes: si fue deliberada y si fue prudente. Vale la pena porque cada cuadrante se gestiona distinto:

1. Deliberada y prudente: «Lanzamos sin reintentos ni cola porque necesitamos validar el mercado este mes; si el producto funciona, lo hacemos bien en el Q2.» Es la deuda sana: decidida, documentada y con plan de pago. Todo equipo que entrega a tiempo la usa.
2. Deliberada e imprudente: «No hay tiempo para tests, nunca hay tiempo para tests.» No es estrategia: es una mala decisión repetida. Se reconoce porque nadie la documenta ni se habla de cuándo se paga.
3. Inadvertida y prudente: «Ahora que entendemos el dominio, vemos que el modelo debería haber sido distinto.» Es inevitable y es señal de aprendizaje — el equipo diseña mejor hoy que ayer. Se gestiona refactorizando al pasar por la zona.
4. Inadvertida e imprudente: «No sabíamos que esto era un problema.» Capas innecesarias, abstracciones por moda, patrones mal copiados. La más cara de todas, porque nadie sabe que existe hasta que explota.

El diagnóstico importa: la deuda deliberada con plan no es un problema, es una herramienta. La inadvertida es la que exige auditoría.

Cómo Saber Cuánta Tienes (Sin Métricas de Humo)

Olvida los contadores de «code smells» como medida de deuda. Las señales que de verdad correlacionan con deuda cara:

• Velocidad de entrega decreciente: si features comparables tardan cada vez más, estás pagando intereses. Es la métrica que negocio entiende sin traducción.
• Hotspots: los ficheros que más cambian y peor estructura tienen. El historial de git te los regala — y suelen ser el 5% del código que causa el 50% del dolor.
• Miedo localizado: pregunta al equipo «¿qué parte del código no tocas si puedes evitarlo?». La respuesta es un mapa de deuda gratis y sorprendentemente preciso.
• Tiempo de incorporación: si una persona nueva tarda meses en ser productiva, la deuda está cobrando entrada.

Si necesitas una fotografía formal y externa, es exactamente lo que revisa una auditoría de código: dimensiones medidas, hotspots con evidencia y un backlog priorizado.

Cómo Se Paga: Estrategias que Funcionan

1. La regla del boy scout (pago continuo): deja cada fichero que toques un poco mejor de lo que estaba. Renombra lo confuso, extrae el método gigante, añade el test que falta. No paga la deuda estructural, pero frena los intereses — y no requiere permiso de nadie.
2. La cuota fija (pago planificado): un 15-20% de la capacidad de cada sprint reservada para deuda, elegida por el equipo técnico desde un backlog visible. Funciona si la cuota es sagrada; si se negocia cada sprint, no es una cuota: es una ilusión.
3. El strangler fig (pago estructural): para los módulos críticos, no reescribas: estrangula. Construye el nuevo camino alrededor del viejo, migra flujo a flujo, y el código legado muere por desuso. Es más lento que la reescritura y es infinitamente menos arriesgado.
4. La gran reescritura (quiebra técnica): tirar y empezar de nuevo. A veces es la respuesta correcta — cuando el dominio cambió tanto que el modelo ya no representa el negocio — pero es la opción con más cadáveres en la historia del software. Si la eliges, que sea con evidencia, no con frustración.

En la práctica, los equipos sanos combinan las tres primeras: boy scout siempre, cuota fija para la deuda conocida, strangler para los monstruos.

Cómo Explicarlo a Negocio (Sin que Suene a Capricho)

La conversación que funciona traduce deuda a dinero y a velocidad, nunca a estética:

• «No es que el código sea feo: es que cada feature cuesta un 30% más que hace un año.» La curva de velocidad es el argumento que ningún director desmonta.
• «Podemos seguir sin pagarla, pero los intereses compuestos no negocian.» La deuda técnica es una de las pocas deudas cuyo tipo de interés sube sola.
• «Pagarla no es un proyecto: es una hipoteca con cuota fija.» Pedir «seis meses para rehacer todo» suena a capricho; pedir el 15% de cada sprint suena a gestión.
• «La alternativa visible es el fracaso: la invisible es la lentitud.» Los sistemas raramente explotan por deuda; se vuelven tan caros de cambiar que el negocio pierde oportunidades sin enterarse.

Errores Comunes

1. Llamar deuda a todo lo que no gusta. Si todo es deuda, nada es prioritario. La deuda es la distancia que encarece el cambio; el resto es preferencia estética.
2. Contraerla sin documentarla. La deuda deliberada sin registro se convierte en inadvertida en dos trimestres: nadie recuerda que fue una decisión ni cuál era el plan de pago.
3. Pagarla sin tocar el producto. Los «sprints de refactoring» aislados fallan siempre: pierden la batalla presupuestaria la primera vez que aprieta un deadline. La cuota dentro del sprint sobrevive; el sprint de deuda, no.
4. Priorizar por fealdad y no por impacto. El código más feo en el módulo que nadie toca cuesta cero euros al año. La deuda se prioriza donde el cambio ocurre.
5. Creer que se puede llegar a cero. Un sistema vivo siempre tiene deuda: la meta no es cero, es un nivel donde los intereses no frenan el negocio.

En Resumen

La deuda técnica es velocidad prestada del futuro: útil cuando es deliberada y documentada, letal cuando es inadvertida o sin plan de pago. Se mide en velocidad de entrega, hotspots y miedo localizado — no en code smells. Y se paga como una hipoteca: cuota continua (boy scout), cuota planificada (15-20% por sprint) y strangler fig para lo estructural. La pregunta no es si tienes deuda — la tienes — sino si la gestionas o te gestiona.

Si tu equipo pierde velocidad sin explicación clara, o la conversación sobre deuda técnica con dirección va siempre mal, podemos ayudarte con las dos cosas: la evidencia técnica y su traducción a negocio. Hablemos de tu caso →

Sigue leyendo: La pirámide de testing: guía práctica para suites que no se desmoronan.