Contenido
El 31 de marzo de 1966, IBM entrega la primera versión de su sistema operativo OS/360 – casi dos años después de anunciarlo. Lo previsto era un único sistema capaz de funcionar ya en máquinas con 32 KiB de memoria. Lo que se entrega necesita al menos 44 KiB. El hombre que dirigió el proyecto formula a partir de esa experiencia una frase que los desarrolladores de software conocen todavía hoy. Un ejemplo del Principio del tamaño.
Un proyecto se retrasa
Situación
Frederick P. Brooks Jr., nacido en 1931, entra en IBM en 1956. Allí dirige el desarrollo de la familia de máquinas System/360 y, después, de su sistema operativo. OS/360 se anuncia en 1964. IBM cifra su tamaño en unos 1,5 millones de instrucciones. El calendario no se cumple. Como solución de emergencia, IBM lanza sistemas más sencillos, entre ellos DOS/360. La gran variante MVT no llega hasta 1967, tras nuevos retrasos.
Relación con el principio
La tarea era enorme, y un equipo pequeño no habría podido con ella. El Principio del tamaño no lo niega. Dice: cada miembro adicional aporta fuerza y cuesta coordinación – un equipo es tan pequeño como la tarea lo permite. Así que la pregunta nunca es “¿grande o pequeño?”, sino: ¿qué cuesta la siguiente persona y qué aporta?
Más gente, más retraso
Situación
Cuando el proyecto se retrasa, Brooks amplía la plantilla. Es el recurso obvio: si el trabajo no sale, hacen falta más trabajadores. En retrospectiva, Brooks concluye que esa decisión aumentó el retraso.
Relación con el principio
Aquí se hace visible la idea central. Cada recién llegado aporta fuerza – pero más tarde. El costo de coordinación, en cambio, llega de inmediato. En un proyecto que ya va con retraso, la fuerza llega tarde y los costos llegan puntuales.
La ley y sus tres razones
Situación
El presidente de IBM, Thomas Watson Jr., pregunta a Brooks por qué los proyectos de software son más difíciles de dirigir que los de hardware. De la respuesta nace en 1975 el libro “The Mythical Man-Month” (en español, “El mítico hombre-mes”). Su frase más conocida es la ley de Brooks: añadir personal a un proyecto de software retrasado lo retrasa aún más. Brooks da tres razones. Primero, a los nuevos hay que formarlos, y eso absorbe tiempo de los más experimentados. Segundo, el número de canales de comunicación crece más deprisa que el número de personas, según la fórmula n(n−1)/2. Con 50 desarrolladores son 1225. Tercero, hay trabajos que no se pueden dividir.
Relación con el principio
La fórmula permite cuantificar los costos de coordinación. Haz la cuenta para tu equipo: cinco personas forman diez parejas posibles; diez personas, 45. El número de personas se duplica; las conexiones se multiplican por más de cuatro. Con esto encaja un hallazgo de los investigadores Bradley R. Staats, Katherine L. Milkman y Craig R. Fox, de 2012: en dos experimentos y en los datos de 594 proyectos de software, el esfuerzo se subestimaba tanto más cuanto mayor era el equipo. Vemos la fuerza adicional y pasamos por alto el precio adicional.
El equipo quirúrgico
Situación
Brooks no se queda en la advertencia. Su contrapropuesta es el “equipo quirúrgico”: un núcleo pequeño en torno a un programador jefe al que los demás asisten – como en un quirófano, donde uno opera y los demás le dan apoyo.
Relación con el principio
Es la segunda mitad del principio convertida en plano de construcción. Si la tarea necesita muchas manos, organízala de modo que no todos tengan que hablar con todos. Pocos deciden, muchos apoyan. Así crece la fuerza sin que la coordinación crezca en la misma medida.
El límite de la ley
Situación
El propio Brooks calificó su ley de simplificación burda. Se aplica a proyectos que ya van con retraso. Quien incorpora pronto a personas con experiencia y divide el trabajo en partes bien separadas atenúa el efecto.
Relación con el principio
El principio no prohíbe crecer. Exige hacer cuentas honestas en el momento adecuado. En una fase temprana, con subtareas claras y gente con experiencia, una persona más puede valer la pena. Tarde y sin una división clara del trabajo, agrava el problema que debía resolver.
Lo que te llevas
Las lecciones más importantes
- Antes de pedir refuerzos en plena crisis, haz la cuenta: quién formará a los nuevos y qué quedará sin hacer mientras tanto.
- No cuentes solo personas, sino conexiones. La fórmula n(n−1)/2 se aplica a cualquier lista de equipo.
- Si la tarea necesita a muchas personas, construye un núcleo pequeño al que los demás den apoyo.
- Comprueba si el trabajo puede dividirse de verdad. Lo que no se puede dividir no avanza más rápido con más gente.
- Amplía pronto o no amplíes. El refuerzo más caro es el que llega justo antes de la fecha límite.
Resumen
En uno de los mayores proyectos de software de su época, Frederick Brooks comprobó que las personas y los meses no son intercambiables a voluntad. Incorporó gente a un proyecto retrasado y vio cómo se retrasaba aún más. Su ley es la fórmula práctica más conocida del Principio del tamaño: el recién llegado cuesta de inmediato formación y coordinación; su fuerza llega después. La respuesta no es seguir siendo pequeño a toda costa. La respuesta es ajustar el tamaño a la tarea – y organizarlo de modo que la coordinación no lo devore todo.