The Mythical Man-Month

The Mythical Man-Month: Essays on Software Engineering is a classic book on software project management written by Fred Brooks.

Reflecting on his time at IBM managing the development of OS/360, Brooks recounts the mistakes made and lessons learned. One of the mistakes was the attempt to add more workers to a project falling behind schedule, in the hope of speeding development. His observation, known as Brooks' law, was simple: "Adding manpower to a late software project makes it later."

Another of his challenges to the idea of expecting results to match labor expended was the assertion that writing an Algol compiler requires six months, regardless of the number of workers involved.

Brooks also describes the second-system effect and advocates prototyping.

The book was first published in 1975. It was republished as an anniversary edition in 1995, adding the essay No Silver Bullet and commentary by the author.

Some invaluable insights from the book

• The Mythical Man-Month: Assigning more programmers to a project running behind schedule, could actually make it even later.
• The Second-System Effect: The second system an engineer designs is the most dangerous system he will ever design, since it will be disastrously overdesigned. Thus, when embarking upon a new project, a project manager should ask for a chief architect, who has at least three or more systems design experience under his belt.
• Progress Tracking: Question: How does a large software project get to be one year late? Answer: One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.
• Conceptual Integrity: In order to make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. A "super cool" idea by someone, may not be included if it does not fit with the overall system design seamlessly. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.
• The Manual: What the chief architect produces are written specifications for the system in the form of the manual. It describes the external specifications of the system in detail i.e. everything that the user sees. The manual can be altered as feedback comes in from the implementation teams and the users.
• The Pilot System: When designing a new kind of system, a team will design a throw-away system (whether it likes it or not). This system acts as a pilot plant that will reveal techniques which will subsequently cause a complete redesign of the system. This second smarter system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer and possibly ruin the system's reputation and maybe even the company's.
• Formal Documents: Every project manager must create a small core set of formal documents which acts as the roadmap as to what the project objectives are, how are they to be achieved, who is going to achieve them, when are they going to be achieved and how much are they going to cost. These documents may also reveal inconsistencies which are otherwise hard to see.
• Project Estimation: When estimating project times, it should be remembered that compilers are three times as hard to write as application programs. And systems programs are three times as hard to write as compilers. And the use of a suitable high level language may dramatically improve programmer productivity. Also, it should be kept in mind how much of the work week will actually be spent on technical issues rather than administrative ones or other non-technical ones, such as meetings or sick leaves.
• Communication: In order to avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible (email, phone, meetings, memos etc.) Instead of assuming something, the implementor should instead ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect.
• The Surgical Team: Brooks muses that "good" programmers are generally 5-10x as productive as mediocre ones. It stands to reason then to have a "good" programmer develop while the rest of a team provides what is needed at the right time. This is in contrast to the modern idea of extreme programming.
• Code Freeze and System Versioning: Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system will therefore need to be changed in order to fulfill the changed requirements of the user. This can only occur upto a certain point, otherwise the system may never be completed. At a certain date, no more changes would be allowed to the system and the code would be frozen. All requests for changes, will be delayed until the next version of the system.
• Specialized Tools: Instead of every programmer having his own special set of tools, each team should have a designated tool-maker that may create tools which are highly customized for the job that team is doing. e.g. a code generator tool that spits out code based on a specification. In addition, system-wide tools should be built by a common tools team, overseen by the project manager.
• Lowering Software Development Costs: There are two techniques for lowering software development costs that Brooks writes about.
  • Though Brooks does not outright say it, he clearly implies in the book that he favors contract workers by suggesting that implementors may only be hired once the architecture of the system has been completed (a step that may take several months, during which time, the implementors may have nothing to do). It stands to reason then that if written today, Brooks may have written in favor of outsourcing of software jobs in the United States to places like Russia, India, Pakistan, and elsewhere.
  • The other technique Brooks mentions is not to develop software at all, but to simply buy it off-the-shelf.

Difficulty of applying Brooks' insights

Many software professionals have lamented the fact that 30 years after the book's first publication they are still working on projects whose managers are still making the mistakes that Brooks identifies. When challenged with this in 2004, Brooks stated with characteristic modest humour: "They call this book the Bible of Software Engineering... and that's because everybody reads it but nobody does anything about it!"zh:人月神话