La verdadera razón por la que tu equipo de ingeniería es lento no son las personas, sino la base de código

• El Codebase Drag es un estado de la base de código que hace que todo el trabajo tome más tiempo del necesario, y como no aparece en dashboards ni reportes de sprint, hace que liderazgo caiga una y otra vez en el círculo vicioso de confundirlo con un “problema de personas”
• Tras años de auditorías de bases de código, se observó que se repetían las mismas 5 señales, y se propone una rúbrica de diagnóstico llamada “auditoría de arrastre de base de código” que las cuantifica de 0 a 2 puntos
• Inflar estimaciones, miedo a desplegar, archivos que “no se tocan”, la mentira de la cobertura y el tiempo hasta el primer commit: las 5 señales provienen de problemas de calidad de la base de código y se distinguen de una falta de capacidad de las personas
• Cuanto más experimentado es un ingeniero, mejor percibe los riesgos de la base de código y por eso se mueve con más cautela, lo que genera la paradoja de que incluso parece más lento; si esto se confunde con un problema de talento, el efecto rebote es agregar más procesos
• Con 4 puntos o más, hace falta invertir directamente en la base de código; con 7 puntos o más, el nivel exige una intervención estructural inmediata

---

Qué es el Codebase Drag

• El Codebase Drag es el fenómeno por el cual la base de código hace que cualquier trabajo tome más tiempo del necesario, y no aparece en reportes de sprint ni dashboards
  • Ejemplo: el equipo del cliente tardó una semana con 2 ingenieros para agregar una función de exportación CSV al panel de administración; el trabajo real era de un día, pero el resto del tiempo se fue en entender cómo modificar el código existente sin romper nada
• Cuando la caída en la velocidad del equipo se repite, liderazgo lo interpreta como un problema de talento y responde con reorganizaciones, más procesos o reemplazos de personal, pero el siguiente equipo choca con la misma pared
• La raíz del problema no son bugs, ni funciones faltantes, ni la deuda técnica en el sentido habitual, sino la propia base de código

5 señales del Codebase Drag

1. Estimación con disculpa (Apology Estimate)

• Es la situación en la que un ingeniero da 2 semanas de estimación para una funcionalidad que en realidad debería tomar 3 días, y liderazgo lo malinterpreta como inflar plazos
• La razón real es el acoplamiento entre módulos, como cuando tocar el módulo de billing también afecta al sistema de notificaciones, sumado a una estructura donde no se sabe hasta dónde se propagará el impacto de un cambio
  • Por hidden default scope o callbacks profundamente anidados, es imposible predecir el blast radius de un cambio sin leer la mitad del código
• Si las estimaciones terminan tomando de forma consistente entre 2 y 3 veces más de lo esperado, no es un problema de estimación sino un problema de costo de la base de código

2. Miedo al deploy (Deploy Fear)

• Aparece el patrón de equipos que evitan desplegar los viernes, o que agrupan despliegues y lanzan versiones grandes con poca frecuencia
• Un equipo cliente operaba con una regla informal de no desplegar después del miércoles, una práctica que nació después de que 3 deploys de jueves terminaran en incidentes durante el fin de semana
  • Las causas eran la ausencia de una estrategia de rollback, tests poco confiables y un pipeline de deploy de 45 minutos
• Según DORA, los equipos elite tienen una tasa de fallas por cambio menor al 5% y despliegan cuando hace falta de inmediato, pero este equipo estaba en el estado de desplegar una vez por semana y esperar con nervios

3. El archivo de “no toques eso” (Don't Touch That File)

• En casi todos los lugares, dentro de los primeros 2 días aparece la frase “no toques ese archivo”
  • Por ejemplo, un controlador de billing con 30 before_action, o un modelo que aparece arriba en git log pero que estructuralmente lleva años sin tocarse
• Si ejecutas git log --oneline --since="2 years ago", el archivo más modificado siempre es el mismo del que te advirtieron; si solo recibe parches pequeños y no hay trabajo estructural, entonces se están tratando síntomas mientras se deja intacta la enfermedad
• El costo real es que funciones que deberían vivir en ese módulo terminan implementadas en otros lugares, y las personas recién incorporadas aprenden a evitar ese archivo en su primera semana: la base de código crece de forma deforme alrededor de zonas muertas

4. La mentira de la cobertura (Coverage Lie)

• Un 80% de cobertura de tests parece saludable, pero en realidad ese número suele sostenerse con tests de serializers, helpers y utilidades que casi nunca se rompen, mientras que 3 modelos centrales que manejan dinero no tienen tests
• La suite de tests existe no para atrapar regresiones, sino para hacer que la métrica se vea bien; los tests pasan y aun así producción se rompe
• Si el CI tarda 40 minutos, los desarrolladores dejan de correr tests en local, así que la cifra de cobertura miente por dos lados: no cubre lo importante, y ni siquiera se ejecutan los tests que sí existen
• La pregunta real no es el número de cobertura, sino “¿cuándo fue la última vez que un test atrapó un bug antes de llegar a producción?”

5. Tiempo hasta el primer commit (Time to First Commit)

• Es el tiempo que pasa desde que le das una laptop a una persona recién incorporada hasta que abre un PR con una corrección real o una funcionalidad pequeña
  • Base de código sana: 1 a 2 días
  • Base de código con drag: más de 2 semanas
• Un cliente tardaba semanas en dejar listo el entorno de desarrollo, pero después de corregirlo, una nueva persona podía configurarlo en 15 a 20 minutos
• La causa principal es el setup rot: el script bin/setup no se actualiza desde el último cambio del entorno, los datos semilla referencian tablas o columnas que ya no existen, y hay 3 variables de entorno sin documentar que solo descubres cuando la app falla al arrancar
• Como los ingenieros actuales ya internalizaron procedimientos no documentados, solo las personas nuevas revelan con precisión cuánto conocimiento implícito exige la base de código

Por qué los buenos ingenieros parecen lentos en una mala base de código

• Las 5 señales actúan en conjunto y agregan overhead a todo el trabajo, uno que no se puede señalar en el standup
  • Un ingeniero que en su trabajo anterior implementaba una funcionalidad en 2 días tarda 1 semana en esta base de código, y cuando intenta explicarlo suena a excusa
• Un estudio de METR de 2025 encontró que desarrolladores experimentados fueron 19% más lentos al usar herramientas de IA, lo que prueba que el cuello de botella no era teclear
• Cuanto mejores son los ingenieros, mejor reconocen el riesgo y más cautela toman, por lo que dejan más holgura en las estimaciones; en cambio, un ingeniero menos experimentado puede no ver el riesgo, desplegar más rápido y causar una caída en producción, haciendo que todo el equipo se vuelva todavía más cuidadoso
• Un cliente cambió 6 equipos en 10 años, incluyendo 2 reemplazos completos: liderazgo exige nuevas funcionalidades, se salta el trabajo sobre deuda, el código llega a un estado irrecuperable, luego se propone un rewrite o separar microservicios, y al terminar con dos sistemas el problema empeora otra vez
• Si liderazgo interpreta la pérdida de velocidad como un problema de talento, solo agrega más proceso a un equipo que ya vive con fricción, empeorando todo; la única intervención que realmente ayuda es modificar el camino mismo

Auditoría de Codebase Drag: cómo diagnosticarlo

• Califica cada una de las 5 señales de 0 a 2 puntos:
  • 0 puntos: no hay problema
  • 1 punto: problema parcial
  • 2 puntos: problema grave
• Con 4 puntos o más, la inversión directa en la base de código debe ir antes que cualquier otra medida

Cómo responder cuando la deuda técnica frena al equipo

• Empieza por la señal con mayor puntaje; no intentes arreglar todo al mismo tiempo
  • Miedo al deploy con 2 puntos: priorizar velocidad del CI, automatización del rollback y mejoras para desplegar en unidades pequeñas
  • Estimación con disculpa como principal problema: priorizar desacoplar el módulo con mayor blast radius
  • Tiempo hasta el primer commit con 2 puntos: invertir un día en arreglar bin/setup y documentar el entorno se recupera en cada nueva contratación
• Si Rails está varias versiones atrasado, una actualización de versión puede funcionar como forcing function que justifique la inversión
• Mide en ciclos de 2 semanas: elige la señal con mayor puntaje, haz un sprint enfocado y mide números concretos como frecuencia de deploy, precisión de estimaciones o tiempo hasta el primer PR
• Conseguir aprobación para invertir es difícil porque el costo de no hacerlo no se ve; decir “hay deuda técnica” convence mucho menos que decir “el acoplamiento entre estos tres módulos hace que cualquier funcionalidad tome casi el doble”
• Con 7 puntos o más, por lo general corresponde empezar con una auditoría de la base de código de una semana

[mbh023]

Totalmente cierto, los proyectos legacy son un cáncer.
Hay cosas que ni siquiera vale la pena rehacer desde cero.

[hanje3765]

¿Está hablando de mí...?

[maedk10]

Parece un texto realmente importante para reducir los costos de mantenimiento.

[cronex]

Por eso a veces rehacerlo desde cero termina siendo más rápido.

[kallare]

Todos saben que poner en orden el codebase es el camino para ganar velocidad a largo plazo,
pero es el mismo tipo de idea que decir que comer bien, hacer ejercicio y dormir bien te hace más saludable.