Los Imperdibles
The Mythical Man-Month: Essays on Software EngineeringThe Mythical Man-Month: Essays on Software Engineering — Frederick P. Brooks Jr.
Ver en Amazon

Enlace de afiliado · precio y disponibilidad en Amazon

También en Kindle

The Mythical Man-Month: Essays on Software Engineering

Frederick P. Brooks Jr. · 1975

¿Preferís escucharlo?

Escuchá «The Mythical Man-Month: Essays on Software Engineering» gratis con una prueba de Audible.

Probar gratis

Publicado en 1975, mucho antes de que existiera internet como lo conocemos, este libro sigue siendo lectura obligada en ingeniería de software. La razón es incómoda: describe problemas de gestión de proyectos que, décadas después, seguimos repitiendo casi sin cambios.

Por qué lo recomienda Jeff Bezos

Este título formó parte de la “Jeff’s Reading List” de Amazon, y según la biografía de Bezos escrita por Brad Stone, The Everything Store, las ideas de Frederick Brooks sobre coordinación y tamaño de equipos están detrás de la famosa regla de las “two-pizza teams” de Amazon: ningún equipo debe ser más grande de lo que pueden alimentar dos pizzas. Es una aplicación directa de lo que Brooks documentó medio siglo antes: más gente en un equipo no significa más velocidad, significa más canales de comunicación que coordinar.

De qué trata

Brooks fue el gerente del proyecto del sistema operativo OS/360 de IBM, uno de los desarrollos de software más ambiciosos —y más atrasados— de su época. El libro es una colección de ensayos que destilan esa experiencia: por qué los proyectos de software se atrasan, por qué agregar programadores a un proyecto ya atrasado casi siempre lo empeora, y por qué la complejidad de coordinar personas crece mucho más rápido que la cantidad de personas.

La ley de Brooks

La idea más citada del libro —hoy conocida como “la ley de Brooks”— dice que sumar mano de obra a un proyecto de software atrasado lo atrasa todavía más. La razón es matemática: cada persona nueva necesita tiempo para aprender el contexto (que sale del tiempo de los que ya saben) y suma canales de comunicación que crecen de forma exponencial, no lineal. Es la base intelectual de por qué hoy se prefieren equipos chicos y autónomos por sobre ejércitos de desarrolladores coordinados desde arriba.

También lo recomienda Paul Graham: como fundador de Y Combinator y programador de toda la vida, la advertencia central del libro —que coordinar personas escala peor que escribir código— es una idea que atraviesa buena parte de sus propios ensayos sobre por qué las startups chicas ganan velocidad que las empresas grandes no pueden igualar.

Para quién es

Para líderes de ingeniería y de producto que arman o rediseñan equipos, y para cualquiera que alguna vez haya escuchado “metámosle más gente para que esto salga antes” y haya sospechado, con razón, que algo no cerraba.

Por ahora disponible solo en inglés; el enlace lleva a la edición aniversario de Addison-Wesley.