Reseña del libro: The Mythical Man-Month: Ensayos sobre ingeniería de software, edición de aniversario

The Mythical Man-Month (MM-M) de Frederick P. Brooks, Jr. es uno de los libros más famosos de toda la literatura sobre desarrollo de software y es posiblemente el libro más famoso sobre gestión de desarrollo de software. Ya hay innumerables revisiones de esta clase, pero la reviso nuevamente en esta publicación para aquellos desarrolladores de software que no la han leído y desean una pequeña descripción general de lo que les gusta de ella. Después de todo, es el título número uno de PC World en la lista de los diez mejores libros de TI que nunca admitir que no ha leído. El título completo de la edición que estoy revisando en esta publicación es The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition.

La "Edición de aniversario" de The Mythical Man-Month (publicada en 1995) agrega contenido significativo más allá de lo que se publicó en la edición original en 1975. La "Edición de aniversario" contiene el libro original en su forma original (aunque con la inclusión de correcciones agregadas en la reimpresión de 1982) y agrega cuatro nuevos capítulos. Los primeros quince capítulos de la Anniversary Edition son los capítulos del libro original. Los capítulos agregados incluyen el artículo independiente pero igualmente famoso IFIPS (1986) / IEEE Computer Magazine (1987) de Brooks No Silver Bullet: Essence and Accidents of Software Engineering y un seguimiento llamado No Silver Bullet ReFired. Los capítulos 18 y 19 de la Anniversary Edition se centran en la perspectiva personal de Brooks de 1995 sobre lo que escribió en 1975.Brooks señala lo que hizo mal y lo que hizo bien (hay muchos más casos de este último que del primero).

Hay numerosas reseñas de The Mythical Man-Month que incluyen una cobertura exhaustiva de los temas y citas de este libro (artículo de Wikipedia, resumen de The Mythical Man-Month de Bernard I.Ng, Algunas ideas de The Mythical Man Month a partir del Capítulo 11, Mes del hombre mítico - Extractos I, El mes del hombre mítico - Extractos II, Conferencia sobre el mes del hombre mítico y Revisión / resumen del Mes del hombre mítico, por ejemplo). En lugar de repetir una descripción general del contenido del libro en su conjunto, me centro en esta publicación en algunos puntos clave y a la luz de algunas de las mejores prácticas e ideologías de software de hoy en día.

Capítulo 19 ("Proposiciones del mítico mes del hombre: ¿Verdadero o falso? ") De la" Edición de aniversario "atraerá especialmente al lector que está impaciente o que no tiene tiempo para leer el libro completo, pero quiere obtener una visión general de las afirmaciones de Brooks. Debido a que Brooks usa este capítulo para presentar "la esencia del libro de 1975" en "forma de esbozo", las afirmaciones de Brooks ("hechos y generalizaciones de tipo regla empírica de la experiencia") de su libro original se presentan en "forma cruda" (aproximadamente 20 páginas). La presencia de este capítulo en la "Edición de aniversario" es otra razón por la que no desgloso el libro capítulo por capítulo aquí. Este capítulo hace más que simplemente resumir las afirmaciones del libro original; también incluye algunas de lasComentarios de 1995 basados ​​en 20 años más de observación y el beneficio de la retrospectiva.

En su publicación The Mythical Man Month: Book Review, Mark Needham concluye su reseña de este libro con la afirmación: "Realmente disfruté leyendo este libro y viendo cómo muchas de las ideas de las metodologías más modernas ya se conocían en la década de 1980 y no son en esencia nuevas ideas ". Estoy totalmente de acuerdo con esta afirmación, aunque la verdad es posiblemente aún más asombrosa: estas fueron observaciones en un libro publicado en 1975 basado en las experiencias de Brooks trabajando en el desarrollo de OS / 360 a mediados de la década de 1960 y en conversaciones posteriores en la finales de 1960s. En otras palabras, algunas de las cosas que podríamos pensar que son "nuevas" o "de moda" hoy han existido y se conocen desde hace 45 años o más. Como nota al margen, esto me recuerda a una presentación de Alan M. Davis en el Denver Java Users Group ("¿Qué hay de nuevo en los nuevos métodos de desarrollo de software?") A finales de 2006 en la que demostró cuántas de las "nuevas" metodologías y Las tácticas de hoy tienen predecesores muy similares en años pasados ​​y cómo parecemos alternar entre ellos durante décadas.

Los siguientes puntos señalados por Brooks son especialmente interesantes cuando uno mantiene el pensamiento en el fondo de su mente que este libro fue publicado en 1975 basado en experiencias de mediados a finales de la década de 1960 (estas citas son del resumen del Capítulo 19, pero se basan en el texto de la edición de 1975):

  • "Los programadores profesionales muy buenos son diez veces más productivos que los pobres ..." [destreza]
  • "" Un equipo pequeño y agudo es lo mejor, la menor cantidad de mentes posible ". [Ágil]
  • "Arreglar un defecto tiene una probabilidad sustancial (20 a 50 por ciento) de introducir otro. Después de cada corrección, uno debe ejecutar todo el banco de casos de prueba previamente ejecutados en un sistema para asegurarse de que no se haya dañado de una manera oscura". [pruebas de regresión]
  • "Vale la pena construir muchos andamios de depuración y código de prueba, quizás hasta el 50 por ciento del producto que se está depurando". [examen de la unidad]
  • "Para mantener la documentación actualizada, es crucial que se incorpore en el programa fuente, en lugar de mantenerla como un documento separado ... incluso la sintaxis del lenguaje de alto nivel no transmite ningún propósito". [Principio SECO]

Hay muchas más observaciones en The Mythical Man-Month que demuestran que Brooks y otros desarrolladores de la época entendían muchos de los mismos conceptos básicos del desarrollo de software que nosotros entendemos (y algunas veces "descubrimos" nuevamente) hoy. Muchos de estos son más conocidos y se mencionan en otras revisiones, por lo que no los enumero aquí, excepto por estas citas obligatorias:

  • "Más proyectos de software han salido mal por falta de calendario que por todas las demás causas combinadas".
  • Ley de Brooke: "Agregar mano de obra a un proyecto de software tardío lo hace más tarde".
  • "Por lo tanto, el hombre-mes como unidad para medir el tamaño de un trabajo es un mito engañoso y peligroso".

Una de las secciones que encontré particularmente oportuna (especialmente para un libro de 1975 en 2011) fue la cobertura de Brooks sobre cómo un arquitecto de software puede influir en la implementación. Esto puede ser especialmente sensible cuando la visión del arquitecto no es implementada por el desarrollador de la forma deseada por el arquitecto. Los consejos de Brooks parecen muy prácticos. Afirma que el arquitecto debe aceptar el hecho de que la persona que implementa el código tiene la "responsabilidad creativa" de esa implementación. Además, advierte que el arquitecto debe tener siempre una idea de cómo implementar cualquiera de sus diseños, pero al mismo tiempo debe estar dispuesto a aceptar un enfoque alternativo igualmente bueno propuesto por la persona que implementa el código. Brooks recomienda además que el arquitecto haga todas las sugerencias con respecto a la implementación "En silencio y en privado, "esté" dispuesto a renunciar al crédito "y esté dispuesto a escuchar las" sugerencias de mejoras arquitectónicas "del implementador. Esto me parece un buen consejo basado en mis experiencias en ambos lados de esta relación.

En el artículo de 2005 citado con frecuencia, seguido raras veces, Brooks afirma:

En realidad, el libro trata más de gestión que de tecnología. La tecnología ha cambiado enormemente, por lo que algunos de los capítulos antiguos están totalmente desincronizados. Por otro lado, la gente no ha cambiado mucho. Por eso Homero, Shakespeare y la Biblia siguen siendo relevantes, porque todos tratan de la naturaleza humana. Creo que eso es parte de la explicación de este libro: los problemas de la gestión de personas en equipos no han cambiado, aunque sí el medio en el que las personas diseñan y las herramientas que utilizan. Algunas personas han llamado al libro la "Biblia de la ingeniería de software". Estoy de acuerdo con eso en un aspecto: es decir, todo el mundo lo cita, algunas personas lo leen y algunas personas lo siguen.

Los conceptos contenidos en esta cita pueden ser lo más importante para transmitir en una revisión de The Mythical Man-Month. El atractivo del libro es su cobertura y enfoque en la gestión de personas. Eso ha permanecido atemporal y sin cambios a lo largo de las décadas. Las tecnologías definitivamente han cambiado significativamente y eso puede ser el mayor aspecto negativo de este libro. Los ejemplos de Brooks basados ​​en productos, herramientas y lenguajes específicos en 1975 eran ciertamente más ilustrativos entonces de lo que son hoy para el lector típico. Por ejemplo, su libro de 1975 llama a PL / I "el único candidato razonable para la programación de sistemas en la actualidad". A veces, parte de la lectura puede ser un poco más desafiante debido a la falta de experiencia directa con los productos que menciona Brooks. Sin embargo, en la mayoría de los casos, esto no es un gran obstáculo al final debido a que el elemento humano es el enfoque del libro y esto no ha cambiado en su mayor parte incluso ahora. En el Capítulo 19 de la Edición Aniversario,Brooks reflexiona sobre la continua popularidad de su libro y afirma: "en la medida en queEl MM-M se trata de personas y equipos, la obsolescencia debería ser lenta ".

El Mythical Man-Month se trata realmente de grandes proyectos de desarrollo de software empresarial. Es importante tener esto en cuenta al leer cosas que pueden parecer obvias para alguien que trabaja en un proyecto pequeño. La última parte de la cita anterior es famosa: "Algunas personas han llamado al libro la 'Biblia de la ingeniería de software'. Estoy de acuerdo con eso en un aspecto: es decir, todo el mundo lo cita, algunas personas lo leen y algunas personas lo siguen ". El libro de Brooks está lleno de referencias bíblicas y obviamente está familiarizado con la Santa Biblia. Lamentablemente, la cita de Brooks "todo el mundo la cita, algunas personas la leen y algunas personas la siguen" es muy cierta hoy. Seguiremos leyéndolo, pero sería bueno hacer más para cambiar las cosas en los proyectos de desarrollo de software a gran escala.

Algunas personas sienten que El mes del hombre míticoes derrotista e incluso deprimente. No tengo la misma sensación al leerlo. Más bien, siento que nos recuerda que ciertos comportamientos son perjudiciales y disfuncionales. También nos recuerda que no debemos esperar a la "próxima gran novedad", sino que debemos continuar mejorando nuestro oficio lo mejor que podamos. Se proporcionan muchos consejos y sugerencias prácticos. A Brooks obviamente le encanta estar en el campo del desarrollo de software y esto se muestra una y otra vez en su libro. Brooks concluye el "Epílogo: Cincuenta años de maravilla, emoción y alegría" del libro, hablando de cómo solía ser capaz de "leer todas las revistas y actas de conferencias", pero finalmente tuvo que renunciar a intereses específicos uno por uno como el el conocimiento explotó. Concluye: "Demasiados intereses, demasiadas oportunidades interesantes para aprender,investigación y pensamiento. ¡Qué situación tan maravillosa! No solo no se vislumbra el final, sino que el ritmo no disminuye. Tenemos muchas alegrías futuras ”. Estoy definitivamente de acuerdo.

Publicación original disponible en //marxsoftware.blogspot.com/ (inspirado en eventos reales)

Esta historia, "Reseña del libro: El mes del hombre mítico: Ensayos sobre ingeniería de software, edición de aniversario" fue publicada originalmente por JavaWorld.