El mito del mes de trabajo: el libro de culto cumple treinta años

Este año se cumplen treinta años de la publicación de una obra extraordinaria llamada â??The Mythical Man-Monthâ? (en adelante MMM) escrita por Frederick Brooks, una referencia obligada sobre metodología de la ingeniería del software y la gestión de proyectos informáticos.

En MMM Brooks reflexiona a partir de sus experiencias como jefe de grandes proyectos en IBM durante los años Ž60, como por ejemplo el desarrollo del sistema operativo OS360, en si mismo un producto muy innovador.

Hace treinta años se publicaban libros sobre Cobol y mainframes, ninguno es relevante hoy en día. 1975 era un año antes de que Jobs y Wozniak construyeran el Apple I; dos años antes de que Bill Gates y compañía fundaran Microsoft. MMM ha superado el paso del tiempo con la gracia de los clásicos.

MMM plantea tres temas fundamentales:

1.El desarrollo de software es como un pozo de alquitrán
2.La idea del mes de trabajo es un mito
3.La integridad conceptual es el aspecto fundamental de todo software

El pozo de alquitrán

Brooks compara el desarrollo de sistemas de software con los pozos de alquitrán que durante la prehistoria engullían animales que, cuanto más luchaban más rápido se hundían en ellos. Independientemente de sus capacidades, ningún animal conseguía escapar a su inexorable destino.

En un pozo de alquitrán, al igual que en un pantano, uno puede lograr sacar a flote una mano o una pierna, pero sacar todo el cuerpo se vuelve más difícil. Brooks traza una analogía entre esta situación y el desarrollo de sistemas de programa. Puede ser fácil desarrollar un programa o componente, pero desarrollar un sistema es mucho más complejo que desarrollar separadamente los elementos que lo componen.

El programa o componente independiente es útil para el programador de garaje, el sistema de programas es útil para muchos. Word, por ejemplo no es un único programa, es un sistema de programas para diferentes clases de usuario.

La principal causa de problemas en el desarrollo de software está en el modelo de planeamiento y distribución de recursos. La estimación de duración de un proyecto es algo muy complicado, se tiende a hacer en horas (o días o meses) y se equiparan las mismas a progreso.

Cuando más horas invertimos, más nos acercamos al final de proyecto y esto en la práctica no es así. La complejidad aumenta con la cantidad de componentes. El desarrollo de un sistema toma más tiempo del que se necesita para desarrollar sus componentes de manera independiente. Además, la convergencia se vuelve más lenta hacia el final del proyecto, mientras que uno podría esperar justamente lo contrario.

La única salida de este pozo de alquitrán es aplicar un proceso de ingeniería consciente y métodos probados de gestión de proyecto.

El mito del mes de trabajo

Otro problema básico señalado en MMM es la idea de que horas y recursos humanos son intercambiables. Este enfoque conlleva la asunción implícita de que si un proyecto está atrasado basta con agregar más mano de obra para solucionar el problema (mano de obra: horas, días o meses de trabajo).

A propósito de este punto Brooks introduce su famosa ley, intencionadamente simplista:

â??Adding manpower to a late software project makes it laterâ?

[Agregar mano de obra a un proyecto de software atrasado lo retrasa aún más]

Supongamos que para finalizar un proyecto a 2 programadores les faltan 3 meses de trabajo. ¿Que tendremos que hacer si queremos terminar en un mes en vez de tres? La respuesta intuitiva parece obvia: ¡Necesitamos 6 programadores y tendremos todo listo en un mes!

2programadores * 3meses = 6pm
Xprogramadores * 1mes = 6pm
X=6pm/1m
X=6p

Para Brooks la medida utilizada para medir la duración de los proyectos (meses, días u horas de trabajo) es intrínsecamente errónea. Esta medida es falsa: si bien el coste de un proyecto es proporcional a la cantidad de meses de mano de obra, el progreso del mismo no lo es. El factor humano y las horas no se pueden conmutar como en una simple multiplicación.

Si lo pensamos bien, es fácil de entender el porqué: el tiempo extra que se agrega por persona va a parar a reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinación de reuniones, actas, explicaciones, formación, alguien que tendrá que actuar como supervisor, este supervisor que tendrá que reportar al jefe del proyecto, etc. Por otro lado existen tareas que simplemente no se pueden dividir y deben ser realizadas por la misma persona.

Brooks señala que el optimismo innato de los programadores también debe ser tomado en cuenta. Cuando planeamos un proyecto pensamos que todo va a salir bien porque el desarrollo depende de nosotros y los factores nos parecen controlables.

A este optimismo perverso se puede agregar que los jefes de proyecto tratar de complacer a sus clientes y se adaptan a los deseos de éstos y no luchan lo suficiente por un ritmo más realista para sus proyectos.

La única manera de terminar antes (o no demasiado tarde cuando el proyecto se retrasa por diferentes motivos) no es agregar programadores, sino descartar funcionalidades prometidas pero aún no implementadas.

Con esta idea Brooks sienta las bases para metodologías modernas de desarrollo de sofware, llamadas de enfoque ágil como DSDM/RAD o Extreme Programming.

Integridad conceptual

La necesidad de definir un modelo mental coherente de la aplicación es sin duda la idea más valiosa del libro. MMM es diseño de interacción de vanguardia. Recordemos que estamos en 1975, aún faltan más de diez años para que Donald Norman publique â??La psicología de los objetos cotidianosâ? y Brooks ya nos habla de la importancia de los modelos mentales en el diseño.

Brooks sostiene que la coherencia del modelo mental de la aplicación y el modelo de interacción subyacentes, que él denomina integridad conceptual, son determinantes de la facilidad de uso de la aplicación y constituyen el aspecto más importante de los sistemas de programación.

El desafío está en que una aplicación grande necesariamente es desarrollada por un equipo de varias personas que deben producir un único modelo mental de la aplicación para el usuario. Sin embargo, nunca hay un único usuario, sino que hay múltiples usuarios y se debe tener en cuenta que diferentes usuarios tienen diferentes necesidades.

¿Cómo organizar el diseño para lograr esta integridad conceptual?
Esto se logra comisionando la preservación de la integridad conceptual y de todos los aspectos perceptibles por el usuario a un arquitecto de sistema, quien diseña la cara pública del sistema en su totalidad y es el responsable final de la misma.

De esto se derivan tres consecuencias fundamentales:

1. El rol de arquitecto es de tal envergadura que, salvo en proyectos pequeños, no puede compatibilizarse con el rol de jefe de proyecto. Si lo comparamos con el cine, el arquitecto es el director y el jefe de proyecto es el productor ejecutivo de la película.

2. Para hacer posible la tarea del arquitecto, es indispensable separar la arquitectura de la implementación. De ahí que el arquitecto sea el responsable de la cara pública que afecta al usuario directamente y no de la implementación. Al ser responsable de la cara pública es el responsable de todas las especificaciones de interfaz (relativas al usuario).

3. En sistemas de gran tamaño puede ser necesario que crear la figura del arquitecto maestro, quien subdivide el sistema en subsistemas y delega partes independientes a otros arquitectos para su diseño. El arquitecto maestro es el responsable de la integración de estos subsistemas y de su coherencia interna.

Epílogo

Leí â??The Mythical Man-Monthâ? por primera vez en 1995 y aunque pude reconocer su importancia, era demasiado inocente e inexperto como para apreciar su valor en la justa magnitud. Ese mismo año se publicó la edición del vigésimo aniversario. Esta edición contiene nuevos capítulos y ensayos que complementan la edición original, así como un capítulo de reflexión sobre la validez histórica de la misma. El cuerpo principal del libro fue reeditado sin cambios, lo cual es una muestra de la confianza del autor en la trascendencia de su texto.

Treinta años después, MMM sigue siendo tan actual como cuando fue publicado por primera vez. Los pozos de alquitrán siguen siendo igual de peligrosos, el mes de trabajo sigue siendo un mito y la coherencia conceptual sigue siendo, hoy más que nunca, el aspecto fundamental de todo software.
Claro que hay pasajes, o capítulos incluso, que se han vuelto obsoletos, pero los capítulos esenciales (1, 2, 4 y en cierta medida el 11) han entrado en el cuerpo de conocimiento de la informática y permanecerán ahí por muchos años.

¿Cómo es posible que este libro paleolítico siga siendo tan actual en un campo donde la vida útil de un libro no pasa de unos pocos años o meses incluso?

MMM trata sobre personas, equipos y principios de desarrollo y no sobre tecnologías. El desarrollo de software sigue siendo cuestión de seres humanos, tal vez sea ésta la razón que hace que MMM siga teniendo vigencia. De la misma manera que Homero y Shakespeare sigue reflejando los dramas humanos actuales, las reflexiones de Brooks siguen marcando el camino a seguir en nuestra industria.