El costo real de una compilación lenta
Una compilación que tarda tres minutos en lugar de treinta segundos no solo cuesta tiempo. Reconfigura silenciosamente cómo trabaja todo tu equipo, y rara vez para mejor.
Nadie agenda una reunión sobre los tiempos de compilación. Van creciendo de una dependencia en una dependencia hasta que una recompilación completa dura lo suficiente para justificar mirar el teléfono. Esa pausa parece inofensiva. No lo es.
El contexto es lo que en realidad pierdes
Cuando una compilación tarda treinta segundos, te quedas dentro del problema. Cuando tarda tres minutos, te vas. Cambias de pestaña, lees un mensaje, sigues un enlace, y para cuando la compilación termina tienes que reconstruir el modelo mental que acabas de soltar. El costo en tiempo de reloj es de minutos. El costo real es la recarga.
Las compilaciones lentas cambian el comportamiento
Los equipos se adaptan a la retroalimentación lenta de maneras que empeoran el código. Agrupan cambios sin probar porque ejecutar el ciclo es costoso. Se saltan la pequeña refactorización porque no vale la pena esperar otra vez. Dejan de escribir el experimento rápido que habría respondido una pregunta con código en lugar de con un debate.
La velocidad de tu ciclo de retroalimentación fija el tamaño del cambio más pequeño que alguien está dispuesto a hacer.
Trátalo como una métrica de primera clase
Mide el tiempo de compilación y de pruebas como mides el tiempo de actividad. Ponlo en un panel. Establece un presupuesto y defiéndelo en las revisiones. Cuando un cambio empuja la compilación más allá del presupuesto, ese es un costo real que sopesar, no un error de redondeo que ignorar.
Las compilaciones rápidas no son un lujo para equipos grandes. Son la base que permite a un equipo pequeño seguir moviéndose como un equipo pequeño.