06.10.2026 · Signal Titans Editorial
Fred Brooks lo aprendió por las malas: más programadores pueden retrasar aún más un proyecto
En los años sesenta, IBM respondió a un proyecto de software retrasado como muchos managers todavía responden hoy: añadir más gente. Fred Brooks vio crecer el equipo hasta superar las 1.000 personas y aprendió una de las leyes más contraintuitivas del software.
Brooks dirigía el trabajo del sistema operativo para IBM System/360, uno de los proyectos informáticos más ambiciosos de su época. El hardware debía servir a toda una familia de máquinas. El software tenía que hacerlas útiles. El calendario se estaba deslizando.
IBM añadió gente.
Luego añadió más.
El proyecto no aceleró mágicamente.
Brooks resumiría después la lección en una frase:
“Añadir personal a un proyecto de software retrasado lo retrasa aún más.”
Se convirtió en la Ley de Brooks.
El error es tratar a las personas como unidades de tiempo intercambiables
En una hoja de cálculo, la plantilla parece lineal. Si una persona necesita doce meses, dos deberían necesitar seis y cuatro, tres.
Eso solo funciona cuando el trabajo puede dividirse limpiamente y todos empiezan a plena velocidad.
El software rara vez funciona así.
Un nuevo ingeniero necesita contexto: arquitectura, herramientas, convenciones, decisiones ya tomadas, errores ya descubiertos y todo aquello que nadie documentó porque “todos lo sabemos”.
Alguien debe transferir ese contexto. Y ese alguien suele estar ya en el camino crítico.
El equipo gana una persona y, temporalmente, pierde parte del tiempo de otra.
La comunicación crece más rápido que la plantilla
Dos personas tienen una relación que coordinar. Tres tienen tres. Cuatro tienen seis. Diez pueden tener cuarenta y cinco relaciones por parejas.
No todas requieren reuniones, pero cada incorporación crea nuevas interfaces: decisiones de diseño, límites de responsabilidad, merge conflicts, dependencias de despliegue, revisiones y supuestos que deben seguir alineados.
El trabajo se reparte entre más manos mientras el sistema de coordinación se vuelve más caro.
Parte del trabajo ni siquiera puede hacerse en paralelo
El punto de Brooks no era simplemente que las reuniones fueran malas.
Hay tareas con una secuencia inevitable. No puedes depurar por completo un comportamiento todavía no implementado. No puedes integrar componentes cuyas interfaces siguen cambiando. No puedes validar una corrección de producción antes de comprender el fallo.
Añadir personas a una tarea secuencial no divide el calendario. Puede añadir coordinación alrededor de algo que sigue teniendo que ocurrir en orden.
Eso no significa que los equipos pequeños sean siempre mejores
La Ley de Brooks se repite a veces con demasiada ligereza. Los proyectos grandes necesitan organizaciones grandes. System/360 estaba muy lejos de ser un proyecto para cinco personas.
La pregunta no es si añadir gente ayuda. La pregunta es cuándo.
Si el trabajo es independiente, las interfaces son estables, el onboarding es barato y las incorporaciones llegan antes de la crisis, la capacidad extra puede ser muy valiosa.
Si el proyecto ya va tarde porque la arquitectura no está clara, la integración falla o el equipo ni siquiera comparte una definición de “terminado”, diez personas nuevas pueden multiplicar la incertidumbre.
La plantilla no repara un modelo mental ausente.
La IA crea la misma ilusión a otra escala
Hoy los “nuevos miembros” ni siquiera tienen que ser humanos.
Los agentes de programación con IA pueden producir código, tests y pull requests con enorme velocidad. Es fácil confundir ese output con capacidad real multiplicada.
Pero alguien debe revisar los cambios, comprender cómo interactúan con el sistema, decidir qué abstracciones conservar, resolver conflictos y asumir responsabilidad cuando producción se comporta de manera distinta al prompt.
Generar trabajo puede volverse más rápido que integrar comprensión.
Es la Ley de Brooks con ropa moderna.
Antes de añadir personas, pregunta qué es lo que realmente va tarde
¿El trabajo es divisible? ¿Una nueva persona puede apropiarse de una pieza independiente sin sincronización constante?
¿La arquitectura es suficientemente estable como para enseñarla? Si los veteranos no pueden explicarla con claridad, el onboarding propagará confusión.
¿Quién entrenará a los nuevos? Cuenta ese tiempo de verdad.
¿El cuello de botella es código, o decisiones, testing, integración, claridad de producto o despliegue?
¿La capacidad extra llegará antes de la fecha límite o después de que el coste de coordinación consuma el tiempo restante?
Brooks no aprendió su famosa ley en un ejercicio académico. La aprendió gestionando software para uno de los sistemas más importantes de IBM y observando cómo la respuesta intuitiva al retraso podía hacerlo aún más difícil de coordinar.
La próxima vez que un proyecto de software vaya tarde, pregunta antes de contratar a cinco personas más: ¿nos faltan manos o nos falta claridad?
Fuentes
- Computer History Museum — Frederick P. Brooks Jr.
- IBM — historia de System/360, incluido el problema del software y la Ley de Brooks
- Addison-Wesley / Pearson — The Mythical Man-Month
- Fred Brooks — No Silver Bullet
- Imagen destacada — Fred Brooks; copyright SD&M, CC BY-SA 3.0 vía Wikimedia Commons. Adaptada a 16:9; la obra derivada mantiene CC BY-SA 3.0.
SIGNAL TITANS.jpg){kind=link}