Deuda técnica
Costo futuro que genera tomar atajos o posponer mejoras en el software: cada cambio posterior se vuelve más lento, caro y riesgoso hasta que la deuda se paga.
Pronunciación
Qué es
La deuda técnica (technical debt) es una metáfora financiera: cuando un equipo toma un atajo para entregar más rápido —o simplemente deja que el sistema envejezca sin mantenimiento— adquiere una “deuda”. Esa deuda cobra intereses: cada nueva funcionalidad cuesta más tiempo y dinero del que costaría sobre un código sano.
Para un gerente: si antes un cambio pequeño tomaba días y ahora toma semanas, y nadie se atreve a tocar ciertos módulos, probablemente estás pagando intereses de deuda técnica.
De dónde viene el término
- Ward Cunningham introdujo la metáfora en la conferencia OOPSLA de 1992.
- Martin Fowler la popularizó explicando el “interés”: el esfuerzo extra que cuesta agregar funcionalidades por culpa de un diseño deficiente. En su ejemplo, si un módulo confuso hace que una tarea de cuatro días tome seis, los dos días extra son el interés.
Los cuatro tipos de deuda (cuadrante de Fowler)
Fowler propuso clasificar la deuda según si fue deliberada o inadvertida, y si fue prudente o imprudente. Cada celda muestra una frase ilustrativa de cómo suena ese tipo de deuda en un equipo:
| Imprudente | Prudente | |
|---|---|---|
| Deliberada | “No tenemos tiempo para diseñar” | “Salgamos ya y asumamos las consecuencias” |
| Inadvertida | “¿Arquitectura por capas? ¿Qué es eso?” | “Ahora sabemos cómo debimos hacerlo” |
No toda deuda es mala: la deliberada y prudente puede ser una decisión de negocio válida (por ejemplo, llegar a tiempo a un lanzamiento), siempre que se registre y se planee pagarla.
Formas comunes de deuda técnica
| Tipo | Ejemplo |
|---|---|
| Código | Duplicación, funciones enormes, valores hardcoded |
| Arquitectura | Todo acoplado en un monolito sin límites claros |
| Pruebas | Sin pruebas automáticas; cada cambio se valida a mano |
| Plataforma | Lenguajes o frameworks sin soporte, como VB6 |
| Operación | Despliegues manuales sin CI/CD |
| Conocimiento | Solo una persona entiende el sistema; no hay documentación |
Por qué importa para empresas en Latinoamérica
Muchos sistemas empresariales de la región crecieron durante años con parches urgentes y equipos que rotaron. El resultado típico:
- Lentitud para competir: los canales digitales no avanzan porque el núcleo no aguanta cambios
- Más bugs en producción con cada entrega
- Riesgo de seguridad por componentes sin actualizaciones
- Dependencia de personas clave
La deuda técnica no aparece en el balance contable, pero sí en los tiempos de entrega, los incidentes y la rotación del equipo.
Errores comunes
❌ Ignorarla hasta que explota → La deuda sin gestionar suele terminar en una migración de emergencia, la más cara de todas
❌ Querer pagarla toda de golpe con una reescritura total → Las reescrituras “big bang” suelen tardar más de lo previsto y congelan el negocio; es mejor pagar por partes, por ejemplo con el patrón Strangler Fig
❌ Tratarla como un problema solo técnico → Pagar deuda es una decisión de inversión: debe priorizarse junto con las funcionalidades de negocio
Ejemplo práctico (ilustrativo)
Un equipo mantiene un sistema de facturación. Cada cambio en impuestos toma semanas porque las reglas están copiadas en varios formularios. Un plan razonable:
- Hacer visible la deuda: listar los módulos que más frenan los cambios
- Proteger con pruebas el cálculo de impuestos antes de tocarlo
- Centralizar la regla en un único servicio
- Reservar capacidad fija en cada sprint para reducir deuda
- Automatizar pruebas y despliegues con prácticas DevOps
Cuando la deuda está en la plataforma misma (lenguaje sin soporte, arquitectura cliente/servidor), la salida es modernizar. En Nextsoft acompañamos estos proyectos junto con aliados estratégicos especializados en migración: el aliado realiza la migración y Nextsoft ejecuta nuevos módulos, integraciones, frontend y QA. Conoce el servicio de modernización de sistemas legacy o conversemos.
Términos relacionados
- Strangler Fig - Patrón para pagar deuda de plataforma por partes
- CI/CD - Automatización que evita acumular deuda operativa
- Hardcoded - Una de las formas más comunes de deuda en el código
- Bug - Síntoma frecuente de deuda acumulada
- DevOps - Prácticas que ayudan a mantener la deuda bajo control
Recursos adicionales:
- Martin Fowler - Technical Debt - La explicación del “interés” de la deuda (en inglés)
- Martin Fowler - Technical Debt Quadrant - Los cuatro tipos de deuda (en inglés)