Ley de Brooks

La Ley de Brooks es un principio utilizado en el desarrollo de software que afirma que "añadir más efectivos a un proyecto de software en retraso, lo retrasará más".​ Fue acuñado por Fred Brooks en su trabajo de 1975 The Mythical Man-Month. El corolario de la ley de Brooks es que cuando se incorpora una persona en un proyecto, este se ralentiza en lugar de acelerarse. Brooks también afirmó que "Nueve mujeres no pueden tener un bebé en un mes".

Significado del término

Según el propio libro de Brooks, la ley es una "frívola sobresimplificación",​ pero se hace eco de la idea. Brooks destaca dos factores principales que explican el porqué de la ley:

1. Nuevas personas en un proyecto necesitan tiempo para ser productivos. Brooks denomina este lapso el tiempo de rampa de subida ("ramp up time"). Los proyectos de software son complejos esfuerzos de ingeniería, y a los nuevos trabajadores en el proyecto hay que enseñarles primero sobre el trabajo que se realizó anteriormente; esta formación requiere tiempo entre aquellos que ya estaban trabajando en el proyecto, disminuyendo su productividad de forma temporal hasta que los nuevos trabajadores tengan una contribución neta. Cada nuevo trabajador también tiene que integrarse en un equipo compuesto por numerosos ingenieros, que han de ayudar en la formación en sus áreas de conocimiento, día a día. Además, es posible que los nuevos miembros del proyecto de por sí tengan una productividad incluso negativa; por ejemplo, si introducen errores en el software por desconocimiento.
2. Aumento de los costes generales (en tiempo) a medida que aumenta el tamaño del proyecto. El número de canales de comunicación diferentes aumenta con el número de personas de forma exponencial; si se dobla el número de personas en el proyecto, el resultado es 4 veces más conversaciones. Todos aquellos que trabajan en un tema necesitan estar sincronizados entre ellos, de forma que si crece el número de personas, también crecerá el tiempo invertido en tratar de averiguar lo que hace el resto.

Excepciones y posibles soluciones

La ley de Brooks se cita a menudo para justificar que los proyectos no se terminan a tiempo, a pesar de los esfuerzos gestores. Sin embargo, hay algunos puntos clave de la ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones.​​

El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso.​ Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases previas.​ También es importante determinar si un proyecto se encuentra realmente en retraso o si las estimaciones iniciales fueron demasiado optimistas, algo frecuente. Corregir la planificación es la mejor manera de disponer de una ventana de tiempo fiable y útil para finalizar el proyecto.​

La cantidad, calidad y papel de la gente que se incorpora al proyecto son factores a tener en cuenta. Una vía simple de evitar la ley en un proyecto en retraso es añadir más gente de la necesaria, de forma que la capacidad extra compensa el overhead en comunicación y formación.​ Los buenos programadores o especialistas se pueden incorporar con menos necesidad de tiempo para su formación.​ También se puede incorporar personal para realizar otras tareas relacionadas con el proyecto, por ejemplo documentación o garantía de calidad en caso de que la tarea esté disponible, así se disminuye el tiempo de la rampa de subida.​

Una buena labor de gestión y desarrollo también ayuda a reducir el impacto de la ley de Brooks. Las prácticas modernas de integración continua, desarrollo guiado por pruebas, y desarrollo iterativo reducen significativamente el overhead de comunicación entre los desarrolladores, permitiendo mejor escalabilidad. También nuevas herramientas para el desarrollo de software y su documentación son de ayuda a minimizar el tiempo de rampa de subida, haciendo más sencilla la incorporación al proyecto. Los patrones de diseño simplifican la distribución del trabajo, dado que el equipo completo puede realizar el trabajo dentro del patrón que se le asignó. Los patrones de diseño definen las reglas que han de seguir los programadores, simplifica la comunicación por medio del uso de un lenguaje estándar y proporciona consistencia y escalabilidad. Finalmente, una buena segmentación ayuda minimizando el overhead entre los miembros del proyecto. Los problemas menores se resuelven en equipos pequeños y un equipo superior es responsable de la integración del sistema. Para poder trabajar así es necesario segmentar el problema de forma correcta; en caso contrario, puede empeorar el problema, impidiendo la comunicación entre los programadores que trabajan en diferentes partes del problema que están directamente relacionados, aunque el plan del proyecto afirme que no los están.

Algunos autores -véase, por ejemplo, Creating a Software Engineering Culture de Karl E. Wiegers – han recalcado la importancia de los aspectos sociales y políticos del clima de trabajo como determinantes de la efectividad de los programadores individuales y del equipo del proyecto como un todo. En lugar de depender de "héroes" para llevar a cabo la tarea con esfuerzos extraordinarios, Wiegers afirma que un equipo de individuales de cualidades ordinarias pueden proveer resultados a tiempo de forma periódica con el ambiente de trabajo correcto. Los esfuerzos para mejorar la efectividad de los equipos puede mitigar sino eliminar, las consecuencias de la ley de Brooks.

Desarrollo de software de código abierto

En comparación con el desarrollo de software tradicional, los proyectos de código abierto tienen una metodología diferente (véase La catedral y el bazar). Los proyectos de código abierto de gran escala tienen un vasto número de participantes que se encargan de programar y garantizar la calidad, utilizando canales de comunicación de bajo coste (como el correo electrónico) para comunicarse. Este tipo de proyectos se escalan bien, a pesar de la Ley de Brooks, debido a varias razones:

• Conceptos de gestión como "cantidad de trabajadores", "tamaño del equipo" y "hoja de ruta" no son análogos en proyectos corporativos y de código abierto; por ello no es posible aplicar la Ley de Brooks de forma equiparable a ambos.
• Los proyectos de código abierto de gran escala tienen la capacidad de hacer uso de muchos usuarios que prueban el código, encontrando los errores más rápido (también conocido por la Ley de Linus);
• Los que realizan las pruebas pueden leer y analizar el código, ayudando a los desarrolladores a determinar los errores de forma más rápida;​
• Trabajo en paralelo eficiente, reduciendo el overhead de comunicación;​
• Un contexto social en el que los contribuyentes lo hace de forma voluntaria, junto con un estilo de dirección sin obligación;​
• Menos confianza en métodos de gestión tradicionales para reducir esfuerzos de duplicados.​
• Una asignación más eficiente de las tareas, tal y como sugirió Yochai Benkler en "Coase's Penguin".

Algunas de estas razones, tales como el trabajo en paralelo, podrían aplicarse teóricamente a ambos, los proyectos abiertos y los cerrados.

Véase también

• Antipatrón de diseño
• Anexo:Filosofías del desarrollo de software

Notas

• Steve McConnell. "Brooks' Law Repealed," IEEE Software, vol. 16, n.º 6, pp. 6-8, nov./dic. de 1999. También disponible en el sitio web del autor (Brooks's Law repealed?).
• Pei Hsia, Chih-tung Hsu, David C. Kung. "Brooks' Law Revisited: A System Dynamics Approach," compsac, p. 370, Twenty-Third Annual International Computer Software and Applications Conference, 1999.
• R. L. Gordon and J. C. Lamb. "A Close Look at Brooks' Law," Datamation, June 977, pp. 81-86.
• Berkun, Scott (11 de enero de 2006). «Exceptions to Brooks’ Law». Consultado el 28 de julio de 2008. 
• Brooks's Law and open source: The more the merrier?
• Brooks' Law Is Applicable To Many Collaborative People Activities
• Eric S. Raymond (1999). The Cathedral & the Bazaar. O'Reilly. ISBN 1-56592-724-9.