Ley de Brooks

Sumar gente a un proyecto de software que ya va tarde, lo hace ir todavía más tarde.

Origen: OS/360

La formuló Fred Brooks en The Mythical Man-Month (1975), después de gestionar el desarrollo de OS/360 en IBM a mediados de los años 60 — uno de los proyectos de software más grandes y problemáticos de la historia. Cuando OS/360 empezó a atrasarse, IBM hizo lo intuitivo: inundó el equipo de programadores nuevos. El proyecto se atrasó más. Brooks se sentó a escribir por qué.

La explicación tiene dos partes: 1) los nuevos necesitan tiempo de los veteranos para entender el sistema (onboarding canibaliza la capacidad existente), y 2) el coste de coordinación crece con el cuadrado del tamaño del equipo: cinco personas tienen 10 caminos de comunicación entre sí, diez personas tienen 45. Cada conversación, cada decisión, cada conflicto de merge, cada review.

Ejemplo

El proyecto que está a dos semanas del demo y se está retrasando. El reflejo del management es traer “dos refuerzos del equipo de al lado”. Esos dos refuerzos no escribieron una línea de este código en su vida, no conocen los acuerdos del equipo, no saben que la integración con el sistema X está rota desde marzo. Tres semanas después, el proyecto sigue tarde y los dos refuerzos están frustrados.

El corolario práctico, también de Brooks: si el proyecto va mal, las palancas que sí funcionan son recortar alcance y mejorar la herramienta o el proceso del equipo que ya está adentro — no agregar cabezas.