Sistemas operativos modernos

ción del cuadrado del número de módulos, es decir, del cuadrado del número de programado- res. Esta complejidad escapa pronto a cualquier control. Mediciones cuidadosas de 63 proyec­ tos de software han confirmado que el equilibrio entre personas y meses dista mucho de ser lineal en los proyectos grandes (Boehm, 1981). Tercera, la depuración es muy secuencial. Poner a 10 depuradores a trabajar en un proble­ ma no hace que el error se localice en una décima parte del tiempo. De hecho, es probable que 10 depuradores serán más lentos que uno solo porque pasarán mucho tiempo hablando. Brooks resume su experiencia con el equilibrio entre personas y tiempo en la ley de Brooks: La adición de personal a un proyecto de software atrasado lo atrasa más. El problema de añadir personas es que es necesario capacitarlas en lo tocante al proyecto; hay que volver a dividir los módulos para que coincidan con el nuevo número de programadores con que ahora se cuenta, se requerirán muchas reuniones para coordinar todas las labores, etc. Abdel-Hamid y Madnick (1991) confirmaron esta ley de manera experimental. Una forma un tanto irreverente de replantear la ley de Brooks es: Se necesitan nueve meses para tener un hijo, por más mujeres que se asignen a la tarea. 12.5.2 Estructura de equipos de trabajo Los sistemas operativos comerciales son grandes proyectos de software y siempre requieren equipos de trabajo numerosos. La calidad de las personas es inmensamente importante. Se sa­ be desde hace décadas que los programadores de primera son 10 veces más productivos que los malos programadores (Sackman etaL, 1968). El problema es que, cuando se necesitan 200 pro­ gramadores, es difícil encontrar 200 programadores de primera; hay que conformarse con una amplia gama de calidades. Otro aspecto importante de todo proyecto de diseño grande, de software o de otra índole, es la necesidad de mantener la coherencia arquitectónica. Debe haber una sola mente que controle el diseño. Brooks cita la catedral de Reims como ejemplo de proyecto grande que tardó décadas en construirse, y en el que los arquitectos que llegaron después subordinaron su deseo de poner su sello en el proyecto, a la necesidad de respetar los planes del arquitecto inicial. El resultado fue una coherencia arquitectónica sin igual en otras catedrales europeas. En los años setenta. Harían Mills combinó la observación de que algunos programadores son mucho mejores que otros con la necesidad de la coherencia arquitectónica, y propuso el paradigma del equipo de programador en jefe (Baker, 1972). Su idea fue organizar un equi­ po de programación como un equipo de cirujanos, no como uno de carniceros. En lugar de que cada uno tire machetazos a diestra y siniestra, una sola persona esgrime el bisturí. Todos los demás están ahí para apoyarla. Para un proyecto de 10 personas, Mills sugirió la estructura de equipo de la figura 12-9. Han pasado tres décadas desde que se propuso esto y se llevó a la práctica. Algunas cosas han cambiado (como la necesidad de un abogado de lenguajes: C es más sencillo que PL/I),