# La ley de Brooks - Sitio: Ikusmira — enciclopedia en castellano de ciencias sociales y humanidades - URL canónica: https://ikusmira.org/p/la-ley-de-brooks/ - Categoría: Informática - Publicado: 2024-06-27 - Autoría: Josemari Sarasola Ledesma — Editor coordinador; Profesor titular de escuela universitaria, Universidad del País Vasco/Euskal Herriko Unibertsitatea - Perfiles del autor: https://ekoizpen-zientifikoa.ehu.eus/investigadores/127490/detalle, https://dialnet.unirioja.es/servlet/autor?codigo=333202 - Política editorial (autoría, revisión, correcciones, financiación): https://ikusmira.org/politica-editorial/ La **ley de Brooks** dice que añadir personas a un proyecto de software que va con retraso lo retrasa todavía más. La formuló **Fred Brooks** en 1975, en su libro *The Mythical Man-Month*, y la presentó él mismo como una simplificación escandalosa, pero ha sobrevivido medio siglo porque contradice la intuición más extendida en la gestión de proyectos: que el trabajo y el tiempo se pueden intercambiar, y que si una tarea necesita doce meses de una persona, doce personas la harán en uno. Brooks no llegó a la idea desde la teoría. A principios de los años sesenta dirigió en IBM el desarrollo del System/360, la familia de ordenadores que por primera vez compartía un mismo juego de instrucciones desde el modelo más modesto hasta el más potente, y después el de su sistema operativo, el OS/360. Este último fue uno de los mayores proyectos de software de su tiempo, con un equipo que llegó a contar con más de mil personas, y acumuló retrasos considerables. Cuando dejó IBM para fundar el departamento de informática de la Universidad de Carolina del Norte en Chapel Hill, Brooks escribió los ensayos que forman el libro para entender qué había salido mal. Su respuesta más célebre fue que el «mes-hombre», la unidad con la que se medían los proyectos, era un mito: personas y meses solo son intercambiables cuando una tarea puede repartirse sin que los trabajadores necesiten comunicarse entre sí, como al cosechar trigo. Programar no es así. El mecanismo tiene tres piezas. La primera es el aprendizaje: una persona que llega a un proyecto en marcha no produce nada útil durante semanas, y además consume el tiempo de quienes tienen que explicárselo, que son justo los que más saben. La segunda es la comunicación. En un equipo de $n$ personas que necesitan coordinarse todas con todas hay $n(n-1)/2$ canales posibles: cinco personas suman diez, diez personas suman cuarenta y cinco, veinte suman ciento noventa. El esfuerzo de mantenerse al día crece mucho más deprisa que la capacidad de trabajo añadida, y llega un punto en que cada incorporación resta más de lo que suma. La tercera es la divisibilidad: hay tareas que no admiten reparto porque cada paso depende del anterior. Brooks lo resumió con una imagen que se ha citado hasta el agotamiento: gestar un hijo lleva nueve meses, se asignen las mujeres que se asignen. Las tres piezas se agravan con el calendario: cuanto más tarde llega el refuerzo, menos semanas quedan para amortizar lo que cuesta integrarlo, y más complejo es el sistema que tiene que aprender. El libro contenía otras ideas que han envejecido igual de bien. Brooks defendía la integridad conceptual, que el diseño de un sistema salga de muy pocas cabezas aunque lo construyan muchas manos, y proponía organizar los equipos como un quirófano, con un programador principal rodeado de especialistas que le apoyan. Advirtió del efecto del segundo sistema, la tendencia a sobrecargar el segundo diseño de un arquitecto con todas las ideas que tuvo que contener en el primero. Y recogió una observación de **Melvin Conway** de 1968, hoy llamada ley de Conway, según la cual los sistemas acaban reproduciendo la estructura de comunicación de la organización que los diseña. En 1986 añadió el ensayo *No hay balas de plata*, donde sostenía que ninguna técnica por sí sola multiplicaría por diez la productividad del software en una década, y que lo difícil de programar es la complejidad esencial del problema, no las herramientas. Recibió el premio Turing en 1999. La ley ha tenido matices serios. En 1989, **Tarek Abdel-Hamid** la sometió a una simulación de dinámica de sistemas y concluyó que añadir personal a un proyecto retrasado siempre lo encarece, pero no siempre lo retrasa: depende de cuándo se incorporan, de cuánta gente y de lo avanzado que esté el trabajo. Una incorporación temprana y moderada, en tareas bien separadas, puede acortar el plazo. El software libre ofreció otro contraejemplo aparente: proyectos como Linux crecieron con miles de colaboradores, aunque lo hicieron con un núcleo pequeño que decide y una arquitectura modular que reduce los canales de comunicación necesarios, es decir, respetando la lógica de Brooks más que refutándola. En la práctica, la ley sirve sobre todo para resistir la tentación de última hora. Ante un retraso, las alternativas que suelen funcionar mejor son recortar el alcance, mover la fecha o proteger a quienes ya conocen el sistema de interrupciones. Si de verdad hace falta más gente, conviene que llegue pronto, que tenga tareas con límites claros y que alguien asuma de forma explícita el coste de integrarla. El tiempo que se pierde enseñando no desaparece porque no figure en el plan. [Ley de Parkinson](https://ikusmira.org/p/ley-de-parkinson/) – [Ley de Murphy](https://ikusmira.org/p/ley-de-murphy/) – [Teoría de colas](https://ikusmira.org/p/teoria-de-colas/) – [El software libre](https://ikusmira.org/p/el-software-libre/) – [El efecto Zeigarnik](https://ikusmira.org/p/el-efecto-zeigarnik/) ## Fuentes - Frederick P. Brooks Jr. — *The Mythical Man-Month*, ACM SIGPLAN Notices 10 (6), 193 (1975) — https://doi.org/10.1145/390016.808439 - Melvin E. Conway — *How Do Committees Invent?*, Datamation 14 (4), 28-31 (1968) — https://www.melconway.com/Home/Committees_Paper.html - Tarek K. Abdel-Hamid — *The dynamics of software project staffing: a system dynamics based simulation approach*, IEEE Transactions on Software Engineering 15 (2), 109-119 (1989) — https://doi.org/10.1109/32.21738 - Frederick P. Brooks Jr. — *No Silver Bullet: Essence and Accidents of Software Engineering*, Computer 20 (4), 10-19 (1987) — https://doi.org/10.1109/MC.1987.1663532 --- Cómo citar: Sarasola, Josemari (2024). «La ley de Brooks». Ikusmira. https://ikusmira.org/p/la-ley-de-brooks/ Índice del sitio para modelos: https://ikusmira.org/llms.txt