La 'Ley de Brooks' sobre el desarrollo de software es un clásico de la profesión... que habría hecho imposible Linux

La 'Ley de Brooks' sobre el desarrollo de software es un clásico de la profesión... que habría hecho imposible Linux
5 comentarios Facebook Twitter Flipboard E-mail

"Cometer un error que cuesta millones es una experiencia humillante, pero también muy memorable". Esta frase no es de Elon Musk, aunque no sea descartable que estuviera dispuesto a suscribirla. Por lo contrario, su autor es el recientemente fallecido Fred Brooks (el pasado jueves, a los 91 años): experto en computación e ingeniero de software, ganador del Premio Turing 1999, responsable del desarrollo del sistema operativo OS/360 de IBM...

...y autor del clásico 'El mítico hombre-mes', conclusión de su experiencia trabajando en IBM y basado en los apuntes de sus primeras clases una vez se pasó al mundo de la enseñanza. Años después diría que la razón por la que a este libro se le considera 'la biblia' en el ámbito de la ingeniería de software es porque "todos lo citan, algunos lo leen y casi nadie lo practica".

Lo cierto es que, si bien algunos de sus consejos evidencian que el libro salió al mercado en 1975 y resultan hoy pintorescos (nadie en estos días imprimiría documentación en microfichas todas las noches para distribuirla a los desarrolladores a la mañana siguiente, por ejemplo), también se hace eco de algunos principios sobre el desarrollo de software que siguen siendo tan aplicables ahora como lo eran hace 45 años.

Así, por ejemplo, cuando abordaba que la respuesta típica ante un retraso en un proyecto es "añadir mano de obra" y lo comparaba como "apagar el fuego con gasolina", formuló el principio que ha pasado a la historia como 'la Ley de Brooks'. Reza así:

"Añadir recursos humanos a un proyecto retrasado hace que se retrase aún más".

Alguna vez también se ha formulado en los siguientes términos:

"Nueve mujeres no hacen un bebé en un mes".

Un problema de adaptación, egos, ojos y manos

Brooks explicaba que esto se debía a que, dado que existe un lapso de tiempo en el que los programadores nuevos tienen que ponerse al día (el lapso de 'subida de la rampa') el resultado de su incorporación es que, mientras el trabajo realizado aumentaba linealmente, la complejidad y los costes de comunicación lo hacían exponencialmente.

Y claro, siempre existía la posibilidad de que el desconocimiento sobre el proyecto provocase que el nuevo 'fichaje' tuviera una productividad negativa (es decir, que al cometer errores, ni siquiera habría aumento lineal del trabajo, sino todo lo contrario).

Eric S. Raymond, en otra obra clásica del desarrollo de software ('La catedral y el bazar', sobre las diferencias entre software privativo y open source) afirmaba que "si la ley de Brooks fuera la verdad absoluta, Linux sería imposible". Para explicar esta aparente contradicción, citaba a otro autor clásico:

"Algunos años más tarde el clásico de Gerald Weinberg 'The Psychology Of Computer Programming' proporcionó lo que puede verse como una corrección fundamental a Brooks. [...] señaló que en aquellos lugares en que los programadores no desarrollan un sentido de la propiedad sobre su propio código, y animan a los demás a buscar errores y posibles mejoras, el desarrollo progresa a una velocidad dramáticamente superior a la habitual".

Ahí es donde entra en funcionamiento una de las dos 'leyes de Linus', así bautizada por el propio Raymond recopilando dos frases del creador de Linux: "Dado un número suficientemente elevado de ojos, todos los errores se vuelven obvios" y "Alguien encuentra el problema y otro lo resuelve".

Es interesante comprender por qué el software libre no invalida la Ley de Brooks, 'promulgada' varios años antes de que éste se popularizara

Es importante ese último añadido, porque Brooks tenía otra teoría al respecto cuando lo único que se multiplicaban eran los ojos, y no los programadores dispuestos a arrimar el hombro:

"El coste total de mantenimiento de un programa de uso generalizado viene a ser de un 40% o más del coste necesario para su desarrollo. Resulta sorprendente, sin embargo, que este coste depende fuertemente del número de usuarios: más usuarios implica que se encuentran más errores".

Eric S. Raymond no menciona el 'lapso de subida de la rampa' y no da respuesta en su libro a la conexión que Brooks establece en entre éste y su 'ley'. Sin embargo, los programadores de proyectos open source tendrían fácil respuesta a esta objeción...

...cuando cualquier usuario con Internet es libre de revisar en un repositorio de GitHub o similar tanto el código de los proyectos como los debates entre desarrolladores en torno al mismo, una vez que se anima a colaborar, desembarca en el proyecto con la 'rampa ya subida'.

Imagen | Basada en original de Phil Whitehouse.

Comentarios cerrados
Inicio