Hay momentos en los que todo el equipo sabe que algo no encaja en el código, pero las prioridades comerciales empujan a seguir construyendo encima de cimientos inestables. El problema aparece cuando un cambio aparentemente pequeño se convierte en un proyecto paralelo que consume semanas y genera nuevos errores.
Los síntomas que no puedes ignorar
El primer aviso habitual es que los estimativos pierden todo sentido. Lo que antes era un día de trabajo empieza a ser «dos sprints porque hay que tocar tres módulos y nadie tiene claro el flujo». Si cada nueva funcionalidad requiere tocar zonas dispersas sin documentación útil, probablemente tienes acoplamiento oculto y ausencia de fronteras claras entre capas.
Otros indicadores recurrentes son:
- Correcciones de bugs que reaparecen tras cambios tangenciales en otra parte del sistema.
- Miedo a desplegar en viernes porque «no sabemos qué puede romperse».
- Tests inexistentes, frágiles o que nadie ejecuta porque tardan una eternidad.
Deuda técnica es un coste financiero real
Cuando una funcionalidad tarda tres veces más de lo esperado, ese tiempo no aparece solo en desarrollo. Se traduce en oportunidad perdida, en que el equipo de producto aplaza experimentos que podrían subir conversiones y en fatiga técnica: las personas brillantes acaban dedicando su energía a apagar fuegos.
Una manera útil de explicarlo a decisores no técnicos es cuantificar en tiempo perdido recurrente. No hace falta un modelo perfecto; basta con reunir algunos episodios recientes («este cambio tardó dos semanas porque…») y proyectar ese patrón.
Auditoría antes de la reescritura fantasiosa
Muchos equipos se plantean desde el día uno tirar todo y construir desde cero. A veces es defendible, pero rara vez es el primer paso correcto si no hay datos. Una auditoría estructurada —mapa del dominio, puntos críticos, riesgos de datos, límites entre front y back— devuelve un plan por fases donde puedes mejorar seguridad acotadas y mantener valor en producción.
En ese proceso reviso habitualmente cómo llegan cambios hasta producción, qué partes tienen alta rotación en Git y si existen zonas donde «solo una persona puede tocar porque es la única que lo entendió».
Por dónde empezar sin parar el mundo
Mis recomendaciones pragmáticas:
- Congelar nueva deuda conscientemente: antes de cualquier refactor grande, dejar claro que no seguiremos repetiendo patrones dañinos.
- Definir límites mínimos entre navegación, negocio y persistencia incluso antes de tener la arquitectura ideal.
- Cubrir el camino crítico: los flujos de ingreso, autenticación o checkout merecen automatización antes que el código interno poco tocado.
Conclusión
Si añadir funcionalidades simples se siente cada vez más arriesgado, no es porque el equipo trabaje menos: es porque el sistema necesita cuidados de arquitectura y priorización explícita. La buena noticia es que con una lectura ordenada del estado actual y mejoras escalonadas suele recuperarse margen estratégico sin un big bang irresponsable.