5 señales de alerta de una deuda técnica crítica

La deuda técnica no avisa

Cada startup que he auditado tenía el mismo discurso: «Sabemos que tenemos deuda técnica, pero no tenemos tiempo para ocuparnos de ella.» El problema es que la deuda técnica no se comporta como una deuda financiera. No genera intereses regulares — explota de golpe, cuando ya es demasiado tarde.

Después de 14 años y más de 30 auditorías técnicas, he identificado 5 señales que no engañan.

1. El tiempo de despliegue se dispara

Cuando un despliegue tarda más de 30 minutos, rara vez es un problema de infraestructura. Es un síntoma:

• Tests inestables que fallan aleatoriamente y que se vuelven a ejecutar «cruzando los dedos»
• Pipeline CI/CD sin caché que reconstruye todo en cada commit
• Sin feature flags, por lo que el código se va acumulando detrás de ramas cada vez más largas

El umbral de alerta: si su equipo duda antes de desplegar un viernes, hay un problema.

Cómo medirlo

Tiempo medio entre un merge y producción
< 15 min → excelente
15-60 min → aceptable
> 1h → deuda crítica

2. Las nuevas funcionalidades tardan 3 veces más

Si una funcionalidad que «debería llevar 2 días» tarda sistemáticamente 6, no es un problema de estimación. Es que cada cambio requiere tocar 15 archivos, entender 3 capas de abstracción innecesarias y rezar para no romper nada.

Las causas habituales:

• Acoplamiento fuerte entre módulos — no se puede tocar nada sin efectos secundarios
• Abstracciones prematuras creadas «por si acaso» y que nunca se usan como estaba previsto
• Sin documentación sobre las decisiones de arquitectura pasadas

3. El bus factor en 1

Si solo una persona entiende el sistema de pagos, la integración con la API o la configuración de despliegue, el bus factor es 1. No es deuda técnica en sentido estricto, pero es un riesgo que se materializa de la misma manera: una dimisión, y todo se detiene.

Señales concretas

• Las code reviews siempre se asignan a la misma persona
• Algunos archivos tienen un único contribuidor desde hace 12 meses
• El onboarding de un nuevo desarrollador lleva más de 2 semanas

4. Los errores en producción son «normales»

Cuando el equipo trata las alertas de Sentry como ruido de fondo, algo se ha roto en la cultura de calidad. Los síntomas:

• Más de 50 errores sin resolver en el tracker
• Bloques try/catch que silencian las excepciones sin registrarlas
• El monitoring existe pero nadie lo mira

En ETX Majelan, lo primero que hice al llegar fue pasar el uptime del 99,2 % al 99,9 %. No con herramientas milagrosas — tomándome en serio cada error.

5. El equipo evita ciertas zonas del código

Si los desarrolladores rodean sistemáticamente un módulo en lugar de modificarlo, es la señal más clara de deuda tóxica. Han aprendido por experiencia que tocar ese código es abrir la caja de Pandora.

La prueba sencilla

Pregúntele a 3 desarrolladores: «¿Qué parte del código les da más miedo?» Si los 3 dan la misma respuesta, esa es su prioridad número 1.

Cómo actuar

La deuda técnica no se salda de golpe. Este es el enfoque que utilizo en las auditorías:

1. Cartografiar — identificar las zonas de riesgo (complejidad, acoplamiento, cobertura de tests)
2. Cuantificar — estimar el impacto en velocidad (cuánto tiempo se pierde por sprint)
3. Priorizar — atacar primero lo que frena la velocidad, no lo que molesta a los puristas
4. Presupuestar — dedicar el 20 % de cada sprint a la remediación, no un «sprint de deuda» cada 6 meses

La deuda técnica no es un fracaso. Es el resultado natural de decisiones tomadas con las restricciones correctas del momento. El problema está en no medirla.