The Mythical Man-Month
Encyclopedia
The Mythical Man-Month: Essays on Software Engineering is a book on software engineering
and project management
by Fred Brooks
, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law
, and is presented along with the second-system effect
and advocacy of prototyping
.
Brooks' observations are based on his experiences at IBM
while managing the development of OS/360. He had mistakenly added more workers to a project falling behind schedule. He also made the mistake of asserting that one project — writing an Algol compiler
— would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it."
The book is widely regarded as a classic on the human elements of software engineering.
The work was first published in 1975 (ISBN 0-201-00650-2), reprinted with corrections in 1982, and republished in an anniversary edition with four extra chapters in 1995 (ISBN 0-201-83595-9), including a reprint of the essay "No Silver Bullet
" with commentary by the author.
Brooks illustrates the fallacy of adding workers to speed the work by counterexample: If one woman can produce a baby in nine months, then nine women should be able to produce a baby in one month. The reason that this is false is that gestation is a sequential process, whose stages cannot run in parallel. If nine women get pregnant at the same time, in nine months they will produce nine different babies.
proposes that, when an architect designs a second system, it is the most dangerous system he will ever design, because he will tend to incorporate all of the additions he originated but did not add (due to inherent time constraints) to the first system. Thus, when embarking upon a second system, an engineer should be mindful that he is susceptible to over-engineering it.
s are both three times as hard to write as in-house programs. It should be kept in mind how much of the work week will actually be spent on technical issues, as opposed to administrative or other non-technical tasks, such as meetings.
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
and project management
Project management
Project management is the discipline of planning, organizing, securing, and managing resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end , undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value...
by Fred Brooks
Fred Brooks
Frederick Phillips Brooks, Jr. is a software engineer and computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package, then later writing candidly about the process in his seminal book The Mythical Man-Month...
, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law
Brooks' law
Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. The corollary of Brooks's Law is that there is an incremental person who, when added to a project,...
, and is presented along with the second-system effect
Second-system effect
The second-system effect refers to the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors. The term was first used by Fred Brooks in his classic The Mythical Man-Month...
and advocacy of prototyping
Software prototyping
*Software prototyping, refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed...
.
Brooks' observations are based on his experiences at IBM
IBM
International Business Machines Corporation or IBM is an American multinational technology and consulting corporation headquartered in Armonk, New York, United States. IBM manufactures and sells computer hardware and software, and it offers infrastructure, hosting and consulting services in areas...
while managing the development of OS/360. He had mistakenly added more workers to a project falling behind schedule. He also made the mistake of asserting that one project — writing an Algol compiler
Compiler
A compiler is a computer program that transforms source code written in a programming language into another computer language...
— would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it."
The book is widely regarded as a classic on the human elements of software engineering.
The work was first published in 1975 (ISBN 0-201-00650-2), reprinted with corrections in 1982, and republished in an anniversary edition with four extra chapters in 1995 (ISBN 0-201-83595-9), including a reprint of the essay "No Silver Bullet
No Silver Bullet
"No Silver Bullet — Essence and Accidents of Software Engineering" is a widely discussed paper on software engineering written by Fred Brooks in 1986...
" with commentary by the author.
The mythical man-month
Assigning more programmers to a project running behind schedule will make it even later, because of the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves, as N increases, their output M decreases and can even become negative: i.e., the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created.- Group Intercommunication Formula: n(n − 1) / 2
- Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication.
Brooks illustrates the fallacy of adding workers to speed the work by counterexample: If one woman can produce a baby in nine months, then nine women should be able to produce a baby in one month. The reason that this is false is that gestation is a sequential process, whose stages cannot run in parallel. If nine women get pregnant at the same time, in nine months they will produce nine different babies.
The second-system effect
The Second-system effectSecond-system effect
The second-system effect refers to the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors. The term was first used by Fred Brooks in his classic The Mythical Man-Month...
proposes that, when an architect designs a second system, it is the most dangerous system he will ever design, because he will tend to incorporate all of the additions he originated but did not add (due to inherent time constraints) to the first system. Thus, when embarking upon a second system, an engineer should be mindful that he is susceptible to over-engineering it.
The tendency towards irreducible number of errors
The author makes the observation that in a suitably complex system there is a certain irreducible number of errors. Any attempt to fix observed errors tends to result in the introduction of other errors.Progress tracking
Brooks wrote "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
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. The architect or team of architects should develop an idea of what the system should do and make sure this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. 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 should describe the external specifications of the system in detail, i.e., everything that the user sees. The manual should 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 intends to or not). This system acts as a "pilot plant" that reveals techniques that 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.Formal documents
Every project manager should create a small core set of formal documents defining the project objectives, how they are to be achieved, who is going to achieve them, when they are going to be achieved, and how much they are going to cost. These documents may also reveal inconsistencies that are otherwise hard to see.Project estimation
When estimating project times, it should be remembered that programming products (which can be sold to paying customers) and programming systemOperating system
An operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system...
s are both three times as hard to write as in-house programs. It should be kept in mind how much of the work week will actually be spent on technical issues, as opposed to administrative or other non-technical tasks, such as meetings.
Communication
To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible — e-mail, phone, meetings, memos etc. Instead of assuming something, the implementer 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 architects are responsible for formulating a group picture of the project and communicating it to the others.The surgical team
Much as a surgical team during surgery is led by one surgeon performing the most critical work himself while directing his team to assist with or overtake less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally five to ten times as productive as mediocre ones. See also Organization and Team Patterns.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 should, therefore, be changed to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes should be allowed to the system and the code should be frozen. All requests for changes should 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 who may create tools that are highly customized for the job that team is doing, e.g., a code generator tool that creates 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:- Implementers may be hired only after the architecture of the system has been completed (a step that may take several months, during which time prematurely-hired implementers may have nothing to do).
- Another technique Brooks mentions is not to develop software at all, but to simply buy it "off the shelf" when possible.