‘The mythical man-month‘ son una serie de reflexiones y ensayos sobre los grandes proyectos de software, su organización y gestión, y algunos de los mitos y concepciones erróneas que les acechan.
- ‘The Tar Pit‘: analiza la diferencia entre la programación de componentes separados o pequeños programas realizados en garages y startups frente a una producción de gran escala de productos y sistemas. También se detiene en las motivaciones, placeres y molestias de la programación.
- ‘The Mythical Man-Month‘: resalta el optimismo casi patológico que afecta a la planificación inicial de los proyectos software y por qué añadir recursos a un proyecto de software retrasado, normalmente lo único que consigue es retrasarlo más.
- ‘The Surgical Team‘: Hace una propuesta arriesgada en cuanto a la forma de organizar un equipo dedesarrollo software a imagen y semejanza de los equipos que realizan intervenciones quirúrgicas. Define el número aproximado, los roles y funcionamiento.
- ‘Aristocracy, Democracy and System Design‘: Se adentra en el concepto de integridad conceptual, defendiendo la importancia de un concepto unitario en el diseño del sistema.
- ‘The Second-System Effect‘: Advierte sobre el peligro de querer añadir demasiadas funcionalidades innecesarias a un producto en su segunda versión.
- ‘Passing The Word‘: analiza la diferencia y uso de la prosa frente al lenguaje formal y diferentes aspectos de comunicación de los conceptos dentro del equipo de desarrollo.
- ‘Why Did The Tower of Babel Fail‘: analiza aspectos de comunicación, documentación y organización
- ‘Calling the Shot‘: se detiene en la problemática de la productividad de los equipos mencionando y comentando algunas aportaciones de terceros.
- ‘Ten Pounds in a Five-Pound Sack‘: estudia aspectos relativos al tamaño del software, un problema que quizá hoy día tiene poca importancia pero que en el momento del desarrollo del OS/360 y de la redacción del libro, sin duda era relevante.
- ‘The Documentary Hypothesis‘: Vuelve a la temática de la documentación, identificando los documentos que considera imprescindibles según el tipo de proyecto.
- ‘Plan To Throw One Away‘: desarrolla una teoría que defiende que la primera versión de un software complejo normalmente está destinada a eliminarla (suele ser muy lenta, muy grande, y difícil de usar), que el sistema adquiere su madurez y utilidad a partir de la segunda versión y que, por tanto, se debe planificar teniendo este hecho en cuenta. En relación con esto plantean también temáticas relacionadas con el cambio.
- ‘Sharp Tools‘: se detiene en aspectos más de detalle como los entornos, las librerias, los lenguajes y las herramientas.
- ‘The Whole and the Parts‘: se centra fundamentalmente en la temática de las pruebas y la depuración del software.
- ‘Hatching a Catastrophe‘: aborda aspectos relativos a la monitorización y seguimiento del proyecto y a la prevenvión de desviaciones y retrasos.
- ‘The Other Face‘: retorna a la problemática de la documentación, incluyendo la documentación de usuario.
- ‘No silver Bullet- Essence and Accident in Software Engineering‘: un interesantísimo ensayo, originalmente publicado de forma independiente en 1986 en «IFIP Tenth World Computing Conference» pero incluido en el libro y cuya tesis es que no se avista ninguna solución milagrosa para incrementar de forma radical la productividad, fiabilidad o simplicidad del software. El ensayo analiza algunas técnicas y tendencias que pueden conseguir mejoras, pero manteniendo la posición de que ninguna de ellas será realmente disruptiva.
- ‘«No Silver Bullet» refined‘: revisa y analiza los comentarios y críticas recibidas por el artículo original.
- ‘Propositions of The Mythical Moan-Month: True or False?‘: resume las ideas principales de todo el libro, capítulo por capítulo
- ‘The Mythical Man-Month After 20 Years‘: hace una análisis en retrospectiva de las ideas del libro, aquellas que considera siguen plenamente vigentes y aquellas en que el autor reconoce haberse equivocado o haber reconsiderado.
‘The Mythical man-month‘ es una obra profunda y en muchos momentos amena, creo que muy acertada en su enfoque e ideas (aunque el propio autor reconoce que a alguna de ellas el tiempo les ha quitado la razón), una obra serena, equilibrada y basada en la experiencia que creo constituye una lectura imprescindible para jefes de proyecto de software o todo aquel con algún tipo de responsabilidad en el mundo del software y los sistemas.
(Fuente: Traducción y ligera elaboración propia a partir de Wikipedia)
Frederick Phillips Brooks, Jr. (nacido el 19 de abril de 1931) es un ingeniero de software y científico de la computación, más conocido por dirigir el desarrollo del sistema operativo OS/360, y después escribir honestamente sobre el proceso en su famoso libro The Mythical Man-Month (El mítico hombre-mes). «Es una experiencia humillante el cometer un error de coste multimillonario, pero es también muy memorable.» Brooks recibió el Premio Turing en 1999 «por sus contribuciones a arquitectura de computadores, sistemas operativos e ingeniería del software.»
Nacido en Durham, Carolina del Norte, asistió a la Universidad de Duke, licenciándose en 1953. Se doctoró en matemática aplicada por la Universidad de Harvard en 1956. Howard Aiken fue su director de tesis.
Brooks se incorporó a IBM en 1956, trabajando en Poughkeepsie y Yorktown, Nueva York. Trabajó en la arquitectura del IBM 7030 (un supercomputador científico de $10M para el Laboratorio Científico de Los Alamos) y los computadores Harvest, para después dirigir
el desarrollo de la familia de computadores System/360 y el software que ejecutaban.
Fue en The Mythical Man-Month cuando Brooks hizo su famosa observación: «Añadir personal a un proyecto retrasado lo retrasará aún más.» Desde entonces, esto se ha venido conociendo como la «Ley de Brooks.» Además de The Mythical Man-Month, Brooks es conocido por su ensayo No Silver Bullet, sobre ingeniería del software.
En 1965, Brooks dejó IBM para fundar el Departamento de Ciencias de la Computación en la Universidad de Carolina del Norte en Chapel Hill del que fue decano durante 20 años. En 2004 estaba aún implicado en actividades investigadoras, principalmente en realidad virtual y visualización científica. En enero de 2005 impartió la clase magistral anual Alan Turing ante la IEE/BCS en Londres, sobre
«Colaboración y Telecolaboración en Diseño».
Puedes saber más sobre el autor consultando visitando su página en la Universidad de Carolina del Norte en Chapel Hill.
PAGINAS: 272
- #macrotweet: la necesidad de un plan de proyecto
- Gestionar mentes
- El software y la segunda ley de la termodinámica
- #macrotweet: sobre el papel del gestor de equipos
- Software y complejidad
- Hardware versus software: ¿Quién corre más?
- Lo que tu jefe necesita saber de tu proyecto
- Usar y tirar: un duro pero quizá inevitable peaje de la innovación
- #macrotweet: el imperativo de intentar
- Tres motivos para documentar un proyecto software… y cualquier otro proyecto…
- #macrotweet: una triste realidad sobre la documentación en proyectos de software
- La organización jerárquica como gestión de la comunicación
- Sobre integridad conceptual, arquitectura empresarial y grandes proyectos de software
- Lenguaje natural versus lenguajes formales
- #macrotweet: la experiencia de un fracaso caro
- El optimismo como defecto… en la planificación de proyectos de software
- Ingeniería de software: ¿por qué es tan difícil pasar del garaje a la factoría?
- #macrotweet: innovación, obsolescencia… y un puntito de realismo
- ¿Por qué nueve mujeres no pueden tener un niño en un mes?
- … y por qué no siempre es divertido programar
- ¿ Por qué nos gusta tanto programar?
