Want to learn the ideas in The Mythical Man-Month better than ever? Read the world’s #1 book summary of The Mythical Man-Month by Frederick P. Brooks Jr. here.
Read a brief 1-Page Summary or watch video summaries curated by our expert team. Note: this book guide is not affiliated with or endorsed by the publisher or author, and we always encourage you to purchase and read the full book.
Video Summaries of The Mythical Man-Month
We’ve scoured the Internet for the very best videos on The Mythical Man-Month, from high-quality videos summaries to interviews or commentary by Frederick P. Brooks Jr.
1-Page Summary of The Mythical Man-Month
The Pleasures and Challenges of Programming
People enjoy programming because they like to make things and solve problems. They appreciate the complexity of it all, as well as learning new skills. Programmers are similar to poets in that their work is mostly mental, but unlike poets, programmers have an impact on the physical world. In addition to having a good command of their craft, programmers must be able to fix any bugs in their code or else risk creating errors for users. As technology advances and new programs emerge over time, existing programs become obsolete.
Large-system programming is difficult. Programmers are optimistic and assume everything will work out well, but the truth is that programmers make a lot of mistakes when they program large systems because people have a fundamental misunderstanding about how work works. The metric called man-month makes dangerous assumptions about how people can be interchangeable as workers, which means that project managers can divide up all the tasks for any given task perfectly so that anyone can do any job with ease. However, this isn’t true of intellectually rigorous tasks like programming – some things cannot be divided and require sophisticated communication processes to teach people how to do their jobs properly and efficiently. As a result, adding more people to a project adds more work – difficult and time consuming work – not less.
A challenge of a large project is organizing the team. The best way to do that is by using a surgical team model, which assigns specific roles and tasks to each member. For example, one person acts as the “chief programmer,” who works with another person who serves as a sounding board for the chief programmer (who may be less experienced). Another person keeps things organized and running smoothly; yet another generates documentation. Other people work on legal issues or create tools that are needed during development. A tester develops test cases for testing the program, just like an operating room nurse would in surgery.
Some cathedrals have discontinuities in their design because different generations of workers saw the project differently. However, Reims cathedral is a striking example of architectural unity. A great program requires conceptual integrity: the single most crucial factor in designing a system is that one mind or very few minds agree on how to do it. This leads to an aristocracy in software design, where only the visionary few are in charge and other people implement their ideas based on feedback from those visionaries. Information must always flow from implementation back to designers who take new data into account as they move through architecture, implementation and realization stages simultaneously.
Organizational Issues
Architects follow similar patterns when they create their work. The first version of any system or design tends to be “spare and clean,” because the architects are careful about spending money on something that isn’t fully formed yet. When ideas occur during the initial phase, people tuck them away for “next time.” Then, by the third version, architects have learned what works well and they limit themselves to it.
When you’re designing a software project, it’s important to have documentation that describes everything the user sees and also leaves out what they don’t see. The style should be clear and unified. You need definitions that are uncommonly specific and precise so there is no confusion or ambiguity. As you move forward, it’s best to hold weekly meetings with people who are working on the project (no advisers or observers). Circulate planned changes in writing before the meeting, but be flexible about problem solving since decisions can only come from those directly involved in the project. In addition, an annual extended session is helpful for covering minor issues and disagreements as well as major decisions made by primary architects of a software project. Log all telephone calls that provide important information from these individuals.
