¿Qué es la deuda técnica?

La deuda técnica es la acumulación de decisiones de diseño o implementación tomadas por conveniencia o bajo presión que generan un coste adicional en el futuro. Al igual que una deuda financiera, si no se paga, genera “intereses”: cada vez cuesta más trabajar con ese código.

El término fue acuñado por Ward Cunningham en 1992 y sigue siendo uno de los conceptos más relevantes del desarrollo de software.

¿Para qué sirve entenderla?

Comprender la deuda técnica permite:

• Tomar decisiones conscientes sobre cuándo asumir esa deuda y cuándo no.
• Planificar tiempo de refactorización antes de que el problema se vuelva inmanejable.
• Comunicar al equipo o al cliente por qué ciertas tareas técnicas son urgentes aunque no sean funcionalidades nuevas.
• Evitar que proyectos pequeños se conviertan en sistemas que nadie quiere tocar.
• Priorizar correctamente entre velocidad a corto plazo y sostenibilidad a largo plazo.

¿Cómo se acumula?

La deuda técnica no siempre es un error. A veces es una decisión deliberada y razonada. El problema es cuando se acumula sin registrarse ni pagarse.

Fuentes habituales:

• Parches rápidos para cumplir una fecha de entrega sin tiempo de hacerlo bien.
• Código duplicado porque era más rápido copiar que abstraer.
• Falta de tests que obliga a probar todo manualmente en cada cambio.
• Dependencias desactualizadas que nadie se anima a actualizar porque “funciona así”.
• Documentación inexistente que hace que cada desarrollador tenga que redescubrir cómo funciona el sistema.
• Malas decisiones de arquitectura tomadas al principio sin prever el crecimiento.

Tipos de deuda técnica

No toda deuda es igual. Martin Fowler propone una distinción útil:

Tipo	Descripción
Deliberada y prudente	”Sabemos que esto no es lo correcto, pero necesitamos publicar ahora y lo arreglaremos después.”
Deliberada e imprudente	”No tenemos tiempo para diseñar bien esto.” Sin intención de repararlo.
Accidental y prudente	”Ahora entendemos cómo deberíamos haberlo hecho.” Aprendizaje natural.
Accidental e imprudente	”¿Qué es un patrón de diseño?” La más peligrosa: no se sabe que existe.

La deliberada y prudente es la única aceptable, y solo si se registra y se paga.

Ejemplo de deuda que se acumula

// Versión rápida para "salir del paso"
function obtenerUsuario(id) {
  // TODO: esto debería buscar en la base de datos
  // por ahora usamos datos hardcodeados
  if (id === 1) return { nombre: 'Ana', rol: 'admin' };
  if (id === 2) return { nombre: 'Luis', rol: 'user' };
  return null;
}

Seis meses después hay 40 funciones así, ningún test, y nadie recuerda dónde están todos los TODO. Eso es la deuda técnica en acción.

Cómo pagarla: refactorización

Pagar deuda técnica significa refactorizar: mejorar la estructura interna del código sin cambiar su comportamiento externo.

// Versión sin deuda: conexión real, separación de responsabilidades
// src/lib/db.ts
import { db } from './connection';

export async function obtenerUsuario(id: number) {
  return db.collection('usuarios').findOne({ _id: id });
}

La refactorización no se improvisa — se planifica. Muchos equipos reservan un porcentaje fijo de cada sprint (el 20% es habitual) para saldar deuda antes de que los intereses se disparen.

La señal de alerta

Cuando el equipo empieza a decir frases como:

• “No toques esa parte que se rompe todo”
• “Hay que reescribirlo desde cero”
• “Nadie sabe cómo funciona ese módulo”
• “Tardé 3 días en añadir una columna a una tabla”

La deuda técnica ha llegado a un nivel crítico. El momento de actuar era antes.

---

---