El asado viene atrasado. Los invitados ya llegaron, la picada se terminó y el asador está solo con la parrilla. Entonces aparece la solución obvia, que es ir a darle una mano. Uno acomoda las brasas, otro da vuelta los chorizos, un tercero opina sobre el punto del vacío. A los veinte minutos el asado sigue igual de atrasado, el asador está de mal humor y nadie sabe quién sacó la morcilla antes de tiempo.
Fred Brooks lo escribió en 1975, en The Mythical Man-Month, después de gerenciar uno de los proyectos de software más grandes de IBM de la época. Agregar gente a un proyecto de software atrasado lo atrasa todavía más. Es la ley de Brooks, y él la resumía con una frase que se sigue repitiendo cincuenta años después: nueve mujeres no pueden tener un bebé en un mes.
Suena contraintuitivo. Si sobra trabajo y falta gente, sumar gente debería ayudar.
Pero la gente nueva llega preguntando. Alguien del equipo le tiene que explicar el contexto, mostrarle el código, revisarle los primeros PRs. Ese alguien casi siempre es de los que más saben, que justo eran los que estaban sacando el proyecto adelante. Durante las primeras semanas, quienes ya estaban tienen que repartir su tiempo entre avanzar y ayudar a los que llegan.
Después está la comunicación. Con tres personas hay tres conversaciones posibles; con seis, quince; con diez, cuarenta y cinco. No todos tienen que hablar con todos, pero cada persona que entra suma vínculos que coordinar. Escribí hace poco que la comunicación es un trade off: armar algo dejó de ser caro y ponerse de acuerdo sigue siendo carísimo. Brooks lo vio medio siglo antes.
Y hay trabajos que directamente no se pueden partir. Si una tarea necesita que otra esté terminada, sumar gente no acorta esa espera. Esas son las del bebé.
Con un proyecto atrasado hay tres perillas: el alcance, la fecha y la gente. La de la gente es la más lenta, porque tarda semanas en hacer efecto y al principio gira para el lado contrario. Si el proyecto llega tarde, casi siempre conviene más recortar alcance o mover la fecha que sumar manos.
Si igual hay que sumar gente, mejor temprano y en partes del trabajo que se puedan aislar, con bordes claros, donde alguien pueda avanzar sin entender todo el sistema. Y alguien que ya conoce el sistema arranca mucho más rápido que alguien brillante que llega de cero.
Si quienes conocen el proyecto se pasan el día explicándolo, les queda menos tiempo para terminarlo.
Con los agentes de IA aparece una versión nueva de la misma pregunta. Si sumar personas tiene este costo, ¿qué pasa cuando sumás agentes que escriben código sin parar? Todavía no tengo idea. Sospecho que el costo de ponerse de acuerdo no desaparece y simplemente se muda a otro lado, pero lo vamos a ver.
Mientras tanto, si el asado viene atrasado, preguntale al asador qué necesita antes de agarrar la pinza.