Priorizar la deuda técnica: ¿pagar intereses o amortizar?

La deuda técnica (en alemán, technische Schulden) son atajos y cargas heredadas en un software que encarecen los cambios futuros, como un crédito por el que se pagan intereses de forma continua. Se prioriza evaluando cada elemento según impacto y esfuerzo, tratando primero los riesgos de seguridad y reservando una parte fija de la capacidad de desarrollo para amortizarla.

Todo proyecto de software acumula con el tiempo cargas heredadas: una solución rápida justo antes del lanzamiento, una actualización aplazada, un módulo que solo entiende una persona. El problema surge cuando nadie sabe a cuánto asciende la deuda. Este artículo muestra cómo hacerla visible, evaluarla y anclarla en el plan, en lugar de contemplar una ralentización progresiva.

Qué es la deuda técnica y qué no es

La metáfora de la deuda procede del desarrollador de software Ward Cunningham, que la acuñó a principios de los años noventa: quien toma un atajo, pide un crédito. Es legítimo mientras se planifique la devolución, porque cada nueva función tarda algo más y cada error cuesta algo más de encontrar. Por eso la deuda técnica no es sinónimo de mal código. Una startup que quiere probar una idea puede elegir soluciones pragmáticas. Lo decisivo es que todos los implicados sepan dónde están esos atajos.

Cuatro tipos de deuda

Resulta útil la clasificación de Martin Fowler, que ordena la deuda según la intención y el cuidado:

Intención	Imprudente	Prudente
Deliberada	«No tenemos tiempo para pruebas.» – se convierte pronto en un problema	«Entregamos ahora y ordenamos después.» – defendible si está documentado y planificado
Involuntaria	falta de conocimientos básicos de arquitectura y calidad: se reduce con revisiones y formación	«Ahora sabemos cómo deberíamos haberlo construido.» – un aprendizaje inevitable

La deuda invisible es el riesgo real

• Pruebas inexistentes: los cambios se convierten en una apuesta, porque nadie sabe con certeza qué se romperá.
• Responsabilidades poco claras: nadie se siente responsable de los módulos centrales.
• Dependencias obsoletas: las bibliotecas y los frameworks van varias versiones por detrás, con vulnerabilidades de seguridad conocidas incluidas.
• Documentación inexistente: el conocimiento está en las cabezas y no en el proyecto.
• Conocimiento en una sola persona: si falta, el módulo se detiene.

Cómo reconocer la deuda técnica en el día a día

Incluso sin analizar el código hay señales de alerta claras que notan la dirección y los departamentos especializados:

• Los cambios pequeños tardan desproporcionadamente.
• Los errores corregidos reaparecen de otra forma.
• El equipo evita ciertas áreas («Mejor no tocar eso»).
• Las actualizaciones se aplazan una y otra vez.
• Los lanzamientos son cada vez menos frecuentes y más arriesgados, porque cada entrega da miedo.
• Los nuevos desarrolladores tardan mucho en ser productivos.

Paso 1: hacer visible la deuda técnica

Lo que no está escrito no se prioriza. Por eso gestionamos la deuda técnica como elementos propios y etiquetados del backlog, en pie de igualdad con las nuevas funciones. Cada elemento incluye una breve descripción, la causa, el impacto concreto y una estimación aproximada del esfuerzo.

Además, dejamos por escrito las decisiones de arquitectura importantes, para que más adelante se entienda por qué algo se construyó así. Las herramientas de análisis estático de código ayudan a encontrar puntos críticos: áreas que se modifican con especial frecuencia y que, al mismo tiempo, son especialmente complejas. Un análisis de las dependencias muestra bibliotecas obsoletas y vulnerabilidades conocidas.

Paso 2: evaluar y priorizar la deuda técnica

No toda la deuda debe saldarse de inmediato. Clasificamos según dos dimensiones: el impacto y el esfuerzo necesario para resolverla. El impacto lo determinan sobre todo estos criterios:

• Seguridad: vulnerabilidades conocidas, actualizaciones pendientes
• Disponibilidad: riesgo de caída en procesos centrales
• Velocidad de desarrollo: con qué frecuencia se modifica el área y cuánto esfuerzo adicional cuesta cada cambio
• Riesgo de conocimiento: solo una persona conoce el módulo
• Requisitos: protección de datos, obligaciones contractuales o el fin del soporte de una plataforma

La matriz de 2×2

Impacto / esfuerzo	Enfoque	Ejemplo
Alto / bajo	abordar de inmediato: el mayor beneficio por hora invertida	actualizar una dependencia con una vulnerabilidad, escribir pruebas para un módulo crítico
Alto / alto	planificar como proyecto propio, presupuestarlo y ejecutarlo por etapas	salto de framework de varias versiones, reestructuración de un módulo central
Bajo / bajo	resolver de pasada, según la regla del boy scout: dejar el código algo mejor de como se encontró	nombres incoherentes, código muerto
Bajo / alto	aceptar de forma consciente y documentar	retoques estéticos en áreas antiguas que casi no se usan

La seguridad es una excepción: las dependencias obsoletas con vulnerabilidades conocidas tienen prioridad, sea cual sea el esfuerzo.

Para hacer tangible el impacto ayuda un cálculo aproximado: intereses al mes ≈ número de cambios en el área × esfuerzo adicional por cambio. Supongamos que un módulo recibe ocho cambios al mes y que cada uno tarda medio día más por la falta de pruebas: entonces la deuda cuesta cuatro días de desarrollo al mes.

Paso 3: anclar la amortización en la hoja de ruta

La deuda técnica compite siempre con las nuevas funciones por la capacidad. Para que no pierda de forma permanente, necesita un lugar fijo: una parte de la capacidad acordada de antemano en cada planificación. Como valor orientativo, los equipos maduros suelen reservar aproximadamente entre una décima y una quinta parte; no es una norma y, en software muy cargado, puede ser temporalmente más. Más importante que la cifra exacta es que la parte sea vinculante y que no sea lo primero que se recorta cuando aprietan los plazos.

La matriz de 2×2 ayuda a justificar ante la dirección estos presupuestos trimestrales. Argumente en el lenguaje de la empresa: no «el módulo X es feo», sino «los cambios en el proceso de pedidos tardan mucho más de lo necesario» o «sin la actualización nos faltan parches de seguridad». Así, un asunto técnico se convierte en una decisión de negocio comprensible. Además, la amortización puede vincularse a funciones ya previstas: si de todos modos va a tocar el módulo de facturación, protéjalo antes con pruebas y ordene de paso.

Ejemplo: el portal de clientes que fue creciendo

Un portal de clientes ha ido creciendo durante años. El framework utilizado tiene varias versiones de antigüedad, apenas hay pruebas automatizadas y solo un desarrollador se atreve ya a modificar el módulo de facturación. Las funciones nuevas tardan claramente más que antes.

En la matriz de 2×2, la actualización del framework queda en lo más alto por las vulnerabilidades de seguridad conocidas. En paralelo se crean pruebas para el módulo de facturación, con un esfuerzo asumible y mucho efecto, porque protegen cada cambio posterior. La reestructuración del propio módulo se planifica como proyecto aparte, por etapas. Los asuntos cosméticos, como los nombres incoherentes, se resuelven de pasada. Así bajan los intereses de forma notable sin que la evolución del producto se detenga durante meses.

Refactoriza­ción en lugar de recons­truc­ción: pasos pequeños y seguros

El error más tentador es la gran reconstrucción. Las reescrituras completas suelen durar más de lo previsto y, mientras tanto, la evolución del producto se detiene o se hace por duplicado, en el sistema antiguo y en el nuevo. Nosotros apostamos, en cambio, por pasos pequeños y seguros:

1. Primero, escribir pruebas alrededor del área afectada.
2. Después, reestructurar en pasos pequeños que puedan entregarse por separado.
3. Activar las nuevas implementaciones detrás de feature flags y volver atrás de inmediato si hay problemas.
4. Eliminar las partes antiguas solo cuando las nuevas funcionen de forma estable.

El mismo principio vale para sustituciones mayores: con el llamado patrón strangler fig se reemplazan funciones concretas, paso a paso, por partes nuevas hasta que el sistema antiguo ya no tiene nada que hacer. Una reconstrucción solo se justifica si la tecnología ya no tiene soporte, apenas se encuentran profesionales para ella o la arquitectura impide de raíz requisitos centrales; y aun así la sustitución suele salir mejor por etapas. Si tiene sentido dividir en servicios individuales lo aborda el artículo Microservicios o monolito.

Evitar nueva deuda y checklist

La deuda técnica no se puede evitar del todo, pero sí controlar. Una Definition of Done vinculante con pruebas y documentación, revisiones de código periódicas, una pipeline de pruebas automatizada y actualizaciones automáticas de dependencias, por ejemplo con Dependabot o Renovate, impiden que la deuda crezca sin que se note. Cómo se ve esto en el día a día ágil lo muestra el artículo sobre Scrum en proyectos de software. También forma parte el mantenimiento continuo: quien aplica las actualizaciones con regularidad evita grandes saltos, tal como lo regula un contrato de mantenimiento.

Checklist: la deuda técnica bajo control

• Deuda registrada como elementos propios del backlog con impacto y esfuerzo
• Evaluación según seguridad, disponibilidad, velocidad de desarrollo y riesgo de conocimiento
• Priorización en la matriz de 2×2, primero los asuntos de seguridad
• Parte fija de la capacidad para la amortización en cada planificación
• Refactorización solo con pruebas y en pasos pequeños
• Definition of Done, revisiones de código y actualizaciones de dependencias como protección frente a nueva deuda

Cómo le ayuda Nano Concepts

¿Sospecha que su aplicación avanza más despacio de lo que debería? En el marco de nuestra consultoría tecnológica evaluamos el estado de su base de código y elaboramos un plan de amortización realista, si lo desea con mantenimiento y evolución posteriores. En la primera consulta gratuita nos expone la situación y después recibe un presupuesto transparente.