Misplaced Pages

The Mythical Man-Month: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 08:13, 5 October 2004 editCesar Moura (talk | contribs)36 editsNo edit summary← Previous edit Latest revision as of 17:54, 20 August 2024 edit undoAndy Dingley (talk | contribs)Autopatrolled, Extended confirmed users, Pending changes reviewers, Rollbackers160,314 edits Restored revision 1233664045 by Jerryobject (talk): Rv introduced typo, and restore the note telling people (except this editor) to not change it and create an errorTags: Twinkle Undo 
(432 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|1975 software engineering book by Fred Brooks}}
'''''The Mythical Man-Month: Essays on Software Engineering''''' is a classic book on ] ] written by ].
{{Infobox book
| name = The Mythical Man-Month
| image = Mythical man-month (book cover).jpg
| caption = First edition
| author = ]
| country = United States
| language = English
| subject = ] ]
| publisher = ]
| pub_date = 1975
| isbn = 978-0-201-00650-6 |isbn_note= (1975 ed.), {{ISBN|978-0-201-83595-3|plainlink=yes}} (1995 ed.)
| dewey = 001.6/425
| congress = QA76.6 .B75
}}
'''''The Mythical Man-Month: Essays on Software Engineering''''' is a book on ] and ] by ] first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as ], and is presented along with the ] and advocacy of ].


Brooks's observations are based on his experiences at ] while managing the development of ]. He had added more ]s to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project—involved in writing an ] ]—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".<!-- NB - "go by" (as in "follow") is correct, not "buy" (as in purchase) --><ref>{{cite news
Reflecting on his time at ] managing the development of ], 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 ], was simple: "Adding manpower to a late software project makes it later."
| url = https://money.cnn.com/magazines/fortune/fortune_archive/2005/12/12/8363107/index.htm
| title = Quoted Often, Followed Rarely
| access-date = 2010-10-23
| work=CNN
| first=Daniel
| last=Roth
| date=2005-12-12
}}</ref>


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


The work was first published in 1975 ({{ISBN|0-201-00650-2}}),<ref name="eecs.umich.edu/~weimerw">{{cite book |last1=Brooks |first1=Frederick P. Jr |title=The Mythical Man-month: Essays on Software Engineering |date=1975 |publisher=] |isbn=0-201-00650-2 |url=https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf |access-date=10 December 2022 |language=en}}</ref> 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 "]" with commentary by the author.
Brooks also describes the ] and advocates ].


== Ideas presented ==
The book was first published in ]. It was republished as an anniversary edition in ], adding the essay '']'' and commentary by the author.


=== The mythical man-month ===
==Some invaluable insights from the book==
Brooks discusses several causes of scheduling failures. The most enduring is his discussion of ]:
* '''The Mythical Man-Month''': Assigning more programmers to a project running behind schedule, could actually make it even more late.
''Adding manpower to a late software project makes it later''. ] is a hypothetical unit of work representing the work done by one person in one month; Brooks's law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book.
* '''The Second-System Effect''': The second system an engineer designs is the most dangerous system he will ever design, since it will be disasterously 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 doesn't fit with the overall system design seamlessly. In fact, to ensure a user-friendly system, a system may deliberately provide '''''less''''' 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 spcifications 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, remember 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, keep 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's implementing, before proceeding with an assumption that might very well be completely incorrect.
* '''Code Freeze and System Versioning''': Software is invisible. Therefore, many things only become apprarent 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 to places like ], ], ], and elsewhere.
**The other technique Brooks mentions, is not to develop software at all, but rather, simply buying it off-the-shelf.


Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
]

Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of the calendar time available. When ''n'' people have to communicate among themselves, as ''n'' increases, their output decreases and when it becomes negative the project is delayed further with every person added.

* Group intercommunication formula: ''n''(''n'' − 1)/2.
* Example: 50 developers give 50 × (50 – 1)/2 = 1,225 channels of communication.

=== No silver bullet ===
{{main article|No Silver Bullet}}

Brooks added the chapter "No Silver Bullet—Essence and Accidents in Software Engineering" and further reflections on it in the chapter "'No Silver Bullet' Refired" to the anniversary edition of ''The Mythical Man-Month''.

Brooks insists that there is no one ]: "there is no single development, in either technology or management technique, which by itself promises even one ] improvement within a decade in productivity, in reliability, in simplicity."

The argument relies on the distinction between accidental complexity and essential complexity, similar to the way ] relies on the distinction between "parallelizable" and "strictly serial".

=== The second-system effect ===
{{main|Second-system effect}}
The ] proposes that, when an architect designs a second system, it is the most dangerous system they will ever design, because they will tend to incorporate all of the additions they originally did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it.

=== The tendency toward 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 that 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 being, if a system is too complicated to use, many features will go unused because no one has time to learn them.

=== The manual ===
The chief architect produces a manual of system specifications. It should describe the external specifications of the system in detail, that is 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 plan" 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 ]s (which can be sold to paying customers) and programming systems are both three times as hard to write as simple independent in-house programs.<ref> Figure 1.1, Page 13</ref> 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, and especially "stand-up" or "all-hands" 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, implementers should ask the architect(s) to clarify their intent on a feature they are implementing, before proceeding with an assumption that might very well be completely incorrect. The architect(s) are responsible for formulating a group picture of the project and communicating it to others.

=== The surgical team ===
Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with 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.

=== 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 their 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 simply to buy it "]" when possible.

== See also ==
*]
*]
*]
*]
*], the assertion that "given enough eyeballs, all ] are shallow" as described in '']''
*'']''
*]

== Bibliography ==
* {{cite book
| title = The Mythical Man-Month
| first = Frederick P.
| last = Brooks
| author-link = Fred Brooks
| publisher = Addison-Wesley
| year = 1975
| isbn = 0-201-00650-2
| url = https://archive.org/details/mythicalmanmonth00broo
}}
* {{cite journal
| title = The Mythical Man-Month
| first = Frederick P.
| last = Brooks
| author-link = Fred Brooks
| journal = PC Magazine
| date = 1983
| volume = 2
| issue = 4
| pages = 210–240
| url = https://books.google.com/books?id=mt9tF7XMFX4C&pg=PA210
}}
* {{cite book
| title = The Mythical Man-Month
| edition = anniversary
| chapter = Chapter 17. 'No Silver Bullet' Refired
| first = Frederick P.
| last = Brooks
| author-link = Fred Brooks
| publisher = Addison-Wesley
| year = 1995
| isbn = 0-201-83595-9
| url = https://archive.org/details/mythicalmonth00broo
}}

== References ==
{{Reflist}}

== External links ==
{{wikiquote|Fred Brooks}}
* {{Official website|www.cs.unc.edu/~brooks}}, University of North Carolina, Chapel Hill
*
*
*

{{Fred Brooks}}

{{DEFAULTSORT:Mythical Man-Month, The}}
]
]
]
]

Latest revision as of 17:54, 20 August 2024

1975 software engineering book by Fred Brooks
The Mythical Man-Month
First edition
AuthorFred Brooks
LanguageEnglish
SubjectSoftware project management
PublisherAddison-Wesley
Publication date1975
Publication placeUnited States
ISBN978-0-201-00650-6 (1975 ed.), 978-0-201-83595-3 (1995 ed.)
Dewey Decimal001.6/425
LC ClassQA76.6 .B75

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping.

Brooks's observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project—involved in 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".

Editions

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.

Ideas presented

The mythical man-month

Brooks discusses several causes of scheduling failures. The most enduring is his discussion of Brooks's law: Adding manpower to a late software project makes it later. Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks's law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book.

Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.

Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added.

  • Group intercommunication formula: n(n − 1)/2.
  • Example: 50 developers give 50 × (50 – 1)/2 = 1,225 channels of communication.

No silver bullet

Main article: No Silver Bullet

Brooks added the chapter "No Silver Bullet—Essence and Accidents in Software Engineering" and further reflections on it in the chapter "'No Silver Bullet' Refired" to the anniversary edition of The Mythical Man-Month.

Brooks insists that there is no one silver bullet: "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity."

The argument relies on the distinction between accidental complexity and essential complexity, similar to the way Amdahl's law relies on the distinction between "parallelizable" and "strictly serial".

The second-system effect

Main article: Second-system effect

The second-system effect proposes that, when an architect designs a second system, it is the most dangerous system they will ever design, because they will tend to incorporate all of the additions they originally did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it.

The tendency toward 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 that 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 being, if a system is too complicated to use, many features will go unused because no one has time to learn them.

The manual

The chief architect produces a manual of system specifications. It should describe the external specifications of the system in detail, that is 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 plan" 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 systems are both three times as hard to write as simple independent 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, and especially "stand-up" or "all-hands" 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, implementers should ask the architect(s) to clarify their intent on a feature they are implementing, before proceeding with an assumption that might very well be completely incorrect. The architect(s) are responsible for formulating a group picture of the project and communicating it to others.

The surgical team

Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with 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.

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 their 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 simply to buy it "off the shelf" when possible.

See also

Bibliography

References

  1. Roth, Daniel (2005-12-12). "Quoted Often, Followed Rarely". CNN. Retrieved 2010-10-23.
  2. Brooks, Frederick P. Jr (1975). The Mythical Man-month: Essays on Software Engineering (PDF). Addison-Wesley Publishing Company. ISBN 0-201-00650-2. Retrieved 10 December 2022.
  3. The Mythical Man-Month Figure 1.1, Page 13

External links

Fred Brooks
Computer
project
management
IBM mainframe computer
Writings, concepts
^ = discontinued
Category:IBM Research computer scientists Category:University of North Carolina at Chapel Hill faculty Category:Turing Award laureates
Categories: