The Mythical Man-Month
.jpg) |
|
| Author | Frederick Brooks |
|---|---|
| Subject | Software project management |
| Publisher | Addison-Wesley |
|
Publication date
|
1975, 1995 |
| ISBN | (1975 ed.), 0-201-83595-9 (1995 ed.) |
| OCLC | 1201368 |
| 001.6/425 | |
| LC Class | QA76.6 .B75 |
| Followed by | "No Silver Bullet" |
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's 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 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 — 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 (), reprinted with corrections in 1982, and republished in an anniversary edition with four extra chapters in 1995 (), including a reprint of the essay "No Silver Bullet" with commentary by the author.
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' 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.
...
Wikipedia