The Mythical Man-Month en alzado

alzado ha publicado un artículo sobre el libro The Mythical Man-Month, del cual yo también hablé hace tiempo (The Mythical Man-Month y Los nuevos Magos).

Es un artículo muy interesante pero quería dejaros algunas notas sobre el mismo.

Por un lado, la traducción elegida para el título me parece que no refleja adecuadamente el sentido. Yo lo hubiese traducido como “El mito del mes/hombre”, tal y como es normal decirlo en la planificación de proyectos, por ejemplo “Esta funcionalidad costará de implementar 3 meses/hombre”, lo que se interpreta como que se necesitarían 3 meses para que una persona realizase ese trabajo (o 1 mes para que 3 personas lo hiciesen, se podría pensar erróneamente)

Efectivamente la idea principal de ese capítulo del libro (que no de todo el libro) es que el concepto de mes/hombre es un mito, algo que no existe y que no es posible intercambiar personas y tiempo. Existen tareas que no se pueden subdividir además de que más personas introducen una sobrecarga de trabajo por la propia comunicación entre las personas. Podríamos decir que “una mujer hace un niño en nueve meses, pero nueve mujeres no hacen un niño en un mes”.

Por otro lado, otra cosa a destacar, y que no se hace en el artículo, es comentar que en realidad el libro es la recopilación de una serie de artículos publicados por la época por su autor. Esto da en cierta manera un carácter “disconexo” al libro, con capítulos muy buenos y otros prescindibles. Por eso, hay capítulos que aun siendo interesante han perdido su vigencia hoy en día. Por ejemplo, el capítulo 3, “The surgical team”, plantea crear un equipo de desarrollo en torno a un “experto” del mismo modo que hay un equipo de apoyo en torno a un cirujano.

Por otro lado, en el artículo creo que se olvidan de algunos de los capítulos que creo que más han aportado a nuestra “cultura ingenieril”, llegando a formar parte del vocabulario de la misma. Haciendo un repaso rápido y por lo que recuerdo de su lectura:

The Second-System effect. Capítulo 5. Habla del peligro de hacer un mal proyecto tras haber completado un buen proyecto, confiado en el éxito del anterior. De esta manera el segundo sistema se sobrecarga con mil funcionalidades que son realmente innecesarias.

No Silver-Bullet. Capítulo 16. Este creo que es un capítulo esencial, básico para nuestra educación como ingenieros y del que yo mismo hablé en mi artículo ¿Se puede programar sin programadores?. Me auto-cito:

Su planteamiento es el siguiente: La programación se compone de dos partes, las partes “intrínsecas” al trabajo de programación (pensar en el problema, resolver las ambigüedades, entender los estándares, “pensar” al fin y al cabo) y las partes que podríamos considerar “accidentales” (expresar la idea en el lenguaje de programación, el propio acto de teclear, etc). Cualquier sistema que aparezca solo puede tratar de acortar las partes “accidentales”. Alguien puede crear un lenguaje de programación más fácil para exponer mis ideas (o que me permita expresarlas con dibujos, como el UML), un reconocedor de voz que me evite escribir en el teclado. Pero puesto que la mayor cantidad de tiempo se va en las partes “intrínsecas” de la programación, no en las “accidentales”, estas herramientas lo máximo que consiguen es un incremento marginal de la productividad.

Este capítulo es tan importante que incluso escribe una actualización (capítulo 17, “No Silver Bullet Refired”) en la edición 20 aniversario.

En definitiva, coincido con Ariel Guersenzvaig, autor del artículo de alzado, en que es un gran libro que cualquier buen profesional debería leer.