The Mythical Man-Month: Essays on Software Engineering

Rate this book

Clear rating

1 of 5 stars 2 of 5 stars 3 of 5 stars 4 of 5 stars 5 of 5 stars

The Mythical Man-Month: Essays on Software Engineering

4.02 of 5 stars 4.02 · rating details · 2,731 ratings · 222 reviews

This is the eBook version of the printed book. If the print book includes a CD-ROM, this content is not included within the eBook version. Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex...more

ebook, Anniversary Edition, Second Edition, 336 pages

Published August 2nd 1995 by Addison-Wesley Professional (first published 1975)

more details... edit details

Get a copy:

More…

Friend Reviews

To see what your friends thought of this book, please sign up.

Lists with This Book

This book is not yet featured on Listopia. Add this book to your favorite list »

Community Reviews

(showing 1-30 of 3,000)

filter | sort: default (?) | rating details

Jun 14, 2012 Igor Tsinman rated it 5 of 5 stars · review of another edition

Shelves: programming, the-best

The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks это уже классика. Все, кто хоть как-то связан с компютерами и/или проектами просто обязаны прочесть эту книгу. Заказчикам тоже не помешает узнать как все выглядит на самом деле.

The Mythical Man-Month это кладезь, хорошо изложеных замечаний, идей, рекомендаций и еще масса прочего полезного материала. 100 процентов идей Брукса актуальны сегодня!!!

В Израильслих стартапх эта книга хорошо известна, а выражение "Silver Bullet"...more

8 likes · like · see review

Sep 06, 2011 Graham rated it 4 of 5 stars · review of another edition

Shelves: computer-books

I read this book originally in college and then re-read it after a couple years of coding professionally. While there are certainly some dated sections, such as the idea of having the analog of a surgical team to code, many of the suggestions have held against the test of time.

The two most popular are "no silver bullets" and "adding developers to a late project makes it later." The former is that no new technology/technique will make an order of magnitude difference in productivity over 10 year...more I read this book originally in college and then re-read it after a couple years of coding professionally. While there are certainly some dated sections, such as the idea of having the analog of a surgical team to code, many of the suggestions have held against the test of time.

The two most popular are "no silver bullets" and "adding developers to a late project makes it later." The former is that no new technology/technique will make an order of magnitude difference in productivity over 10 years ago. This is especially important when dealing with vendors or the latest proselytizer of a language or process ideology. I find this is a nice complement to Robert Glass's opinion that the biggest difference in productive teams is the quality of the developers. The second is more self-explanatory. The ramp up cost of adding new developers exceeds the value they will deliver within a reasonable amount of time.

There are also less referenced lessons to be gleaned from the book. For example, long before Agile, this book eschewed waterfall development in favor of an iterative approach. My favorite lesson in the book is that of conceptual integrity. In essence this is how Brooks refers to the idea that a piece of software should do one thing well and if it tries to fit many roles it will be a poor fit for all of them, instead of a good fit for one. As an example, he cites several Cathedrals that took centuries to complete. The Cathedrals that fell victim to egotistical architects in the middle or later stages of construction are less aesthetically consistent and therefore appealing than those in which the original style was respected.

Brooks also recommends keeping two independent career tracks for developers. In many organizations developers are forced into management after a certain level. Brooks argues this is a mistake and that in many cases it is better to let some developers stay developers. This requires title and compensation parity with the management track.

While many of the technology specific examples are dated, Mythical Man Month is a recommended read for every developer. (less)

5 likes · like · see review

Mar 04, 2012 Megha rated it 3 of 5 stars · review of another edition

Shelves: non-fiction

04/23/11

Dr. Brooks is the founder of our department, more than enough reason to read his book.

The recent extension to our department building was named after Dr. Brooks. Apparently the money for the building came as an anonymous donation from an alumnus, on the condition that it be named after Dr. Brooks. That is the kind of respect he has won from several people.

3 likes · like · see review

Nov 23, 2011 Joecolelife rated it 5 of 5 stars · review of another edition

Recommended to Joecolelife by: www.CocoMartini.com

Shelves: college-textbooks

There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.

In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to manage." This short...more There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.

In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to manage." This short book (at just over 300 pages) does a masterful job answering that question.

It is here we first hear of Brooks's Law: "Adding manpower to a late software project makes it later." Brooks doesn't just drop that on the reader without explanation. Instead, he walks through the reasoning, discusses how communication in a group changes as the group changes or grows, and how additions to the group need time to climb the learning curve.

Those new to the industry or who are reading the book for the first time might be put off by the examples and technology discussed. Indeed, even in the newly released edition, the original text from 1975 is still present, essentially untouched. So, talk of OS/360 and 7090s, which permeates the text, is perhaps laughable to those not looking deeper. When talking about trade-offs, for example, Brooks offers "... OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is day 366). That might have been left to the operator." This is 26 bytes he's talking about!

Brooks provides a light, almost conversational tone to the prose. This isn't to say the observations and analysis were not very well researched. Comparing productivity number with those of Software Productivity Research (SPR), you'll find Brooks came up with the same measurements for productivity as Jones--only 20 years earlier!

Other wisdom is also buried in this work. Brooks declares "The question, therefore, is not whether to build a pilot system and throw it away. You will do that. The question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers." The state of products I buy today tells me not enough people have taken Brooks's observations to heart!

The latest version of the text includes his work "No Silver Bullet." Brooks, who had brought us so much before, had one last "parting shot."

As I started this review I will also end it: this book is a classic. Read it.(less)

like · see review

May 21, 2013 Duncan rated it 5 of 5 stars · review of another edition

After some 50 years this book is still crucially relevant today. A lot of people seem to have read the "No Silver Bullet" essay, but not nearly as may have actually read the whole book. While that essay is a great (if bleak) read, this book has so much more to offer. I found that page after page contained nugget after nugget of wisdom, and I saw many instances both past and present of where organisations I have been a part of have fallen foul of many of the mistakes outlined in the book. I think...more

like · see review

Oct 16, 2011 Sondra Willhite rated it 2 of 5 stars · review of another edition

I decided to revisit a few classic management books recently, and I'd always been curious about this one, since it's specific to my field. Originally published in 1975, much has changed in the business of developing software. Most of Brooks examples are taken from OS development teams, and a few chapters emphasize the old tradeoff of memory and speed or functionality. He even suggests that documentation be kept on microfiche. However there is much that is still relevant, such as the usual busine...more

5 likes · like · see review

Aug 03, 2011 Dan Cohen rated it 4 of 5 stars · review of another edition

Reading this book has been on my "to-do" list for about 20 years so I'm pleased I finally got round to it and it didn't disappoint. Of course, it's an old book (with some additional newer material added) and some of what it covers no longer applies or has been superseded. However, there is still massive relevance in much of what Brooks said back in 1975 and it's amazing how much of it is still largely ignored.

Tomorrow morning I will go back into work as usual on a programme with projects behind...more

like · see review

Jul 19, 2010 getAbstract rated it 5 of 5 stars · review of another edition

Philosophical essays on software, projects and purpose

This book is a classic for a reason. Every essay by Frederick P. Brooks Jr. addresses software engineering and proves invaluable for those interested in the history and processes of that field. getAbstract also recommends Brooks’ book to anyone who plans or organizes major projects. The collection remains timely due to the clarity of his thought and the educated loveliness of his prose. When Brooks is writing about programming, he’s never jus...more

like · see review

Apr 18, 2010 Mouly rated it 5 of 5 stars · review of another edition

* Estimating software project completion time is really hard. (Requirements change, software is intangible and it has to fit with idiosyncrasies of human systems)

* Aristocracy in managing projects is better. There should be one final decision maker. Metaphor is a surgical team.

* Cost of coordination and communication within large teams is often ignored. This causes poor estimation.

* If a project is delayed - rescheduling or reducing scope is recommended. Adding manpower will result in further de...more

1 like · like · see review

Aug 06, 2009 Arden rated it 2 of 5 stars · review of another edition

I had heard about this book and the concept of the "Mythical Man Month" before I found it in my college library this summer. I was really excited to read it after finishing the first chapter, but the more I read it, the more dated it seemed. There are several references to high level languages such as Ada and the promising emergence of object oriented programming that were startling reminders that this book was originally published in 1975. I did appreciate reading it for the historical perspect...more

like · see review

Jul 11, 2009 Nicholas rated it 3 of 5 stars · review of another edition

Shelves: management, programming, business

This review has been hidden because it contains spoilers. To view it, click here. The beginning of it was awesome. After that I didn't understand anything.

Quotes:

"Why is programming fun? What delights may its practitioner expect as his reward? First is the sheer joy of making things. Second is the pleasure of making things that are useful to other people. Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principle built in from the beginning. Fourth is the jo...more The beginning of it was awesome. After that I didn't understand anything.

Quotes:

"Why is programming fun? What delights may its practitioner expect as his reward? First is the sheer joy of making things. Second is the pleasure of making things that are useful to other people. Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principle built in from the beginning. Fourth is the joy of always learning."

"The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them."

"Thinkers are rare; doers are rarer; and thinker-doers are rarest."

"The project was large neough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer."

"The first-line manager's interests and those of the boss have an inherent conflict here. The first-line manager fears that if he reports his problem, the boss will act on it. Then his action will preempt the manager's function, diminish his authority, foul up his other plans. So long as the manager thinks he can solve is alone, he doesn't tell the boss...The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status. I once knew a boss who invariably picked up the phone to give orders before the end of the first paragraph in a status report. That response is guaranteed to squelch full disclosure. Conversely, when the manager knows his boss will accept status reports without panic or preemption, he comes to give honest appraisals."(less)

like · see review

Dec 03, 2012 Kristofer Carlson rated it 4 of 5 stars · review of another edition

Shelves: science-and-technology

This is a classic in the field of computing. Any programmer, systems analyst, or information systems project manager worth his or her salt will have read this book. Given all that has changed since the book was written, it is surprising how well it has held up. I suppose for the young programmer, the recent college graduate, the lessons from the development of one of the early mainframe computer systems might not seem relevant. However, as noted in the extra chapters contained in the twentieth a...more

like · see review

Mar 04, 2012 Caroline Gordon rated it 4 of 5 stars · review of another edition

Shelves: management, project-management, software-development

The "No Silver Bullet" essay should be required reading for all software engineering professionals. However, I have to say the whole book didn't quite live up to the hype for me. I've had 20 years in the industry, I think people with similar history will know (they've seen it) that there is no silver bullet, and that we are basically struggling with the same issues that we have since the inception of software development.
However, I am going to recommend this as '5' stars for less recent entrant...more

like · see review

Apr 16, 2008 Jeanne rated it 2 of 5 stars · review of another edition

Shelves: career

I found the essays informative, from a historical and theoretical perspective, but not a lot of help in how to improve management of projects. There are many far better books than this one for actual "how to" tips and tricks.

1 like · like · see review

Aug 20, 2012 Vasil Kolev rated it 5 of 5 stars · review of another edition

Shelves: tech, why-didnt-i-read-this-10-years-ago, must-read

I should've read this 10 years ago.

I've heard most of the stuff in the book before, in different places and in different articles, but the summation helps a lot with the understanding. Some examples are extremely outdated and might sound like sorcery to most people, but it's not that hard to map them to the current technology (where appropriate).

The book is also a very good thing to bash some managers' heads with, because sometimes you can get tired of saying that although one woman can deliver...more

like · see review

Jan 11, 2010 Chibimagic rated it 4 of 5 stars · review of another edition Recommends it for: managers, and anyone that has to deal with managers

Shelves: programming

This book is one of the classics of software engineering, and with good reason. Though half the book is only applicable if you're building an operating system in the 1960s, the other half remains very much true today. You can see the foundations of agile and a formal QA process. It's remarkable how after 35 years, we still haven't learned some of the lessons that were recognized in the 70s: a single visionary for conceptual integrity, separate parallel managerial and technical career ladders, es...more

like · see review

Jan 06, 2012 Ondřej Sýkora rated it 4 of 5 stars · review of another edition

Shelves: software-development

See how software was developed 50 years ago. It was interesting to observe, how many things have changed since the microcomputer revolution and thanks to the rate, with which the development in hardware and software had progressed. And how the time of the people programming the computers became incomparably more valuable than the computer time.

Though, this is more a book abound managing development than the actual programming, and it is even more interesting to see that so many management proble...more

like · see review

May 23, 2012 Senthil Kumaran rated it 5 of 5 stars · review of another edition

Shelves: computer-science

This is a master piece of software engineering. Many people have read this one because this one is an extremely approachable account. When I read this book in 2007, I felt how much of value this one book brought which was written more than 20 years ago brought even then. Since then, I have heard many people talk and swear by this book. I have one gripe against the readers and people who talk about this. They use this book to support their stances and most often these people do not possess the ki...more

like · see review

Nov 22, 2011 Sergey Kostrukov rated it 2 of 5 stars · review of another edition

The book definitely is out of date.
Everything is completely changed - approaches, principles of teamwork.

I'm wondering why so many people gave good ratings to this book?

30 years ago software development was very expensive because of poor technologies, crap hardware, absence of helper tools - you had to think ten times before actually do something.

Nowadays, time to market is the key principle. You have to push something to public first, then think about aftermath.

One single thought in this book i...more

like · see review

Jan 03, 2010 Jeb rated it 2 of 5 stars · review of another edition

I know that this is the book on the management and leadership of software engineering, but I have to say that I was a little let down.

First of all, it was incredibly dated. Can't blame the author for that, certainly, but useful suggestions about how a team of programmers ought to share a terminal session mean nothing when I've got four powerful computers on my desk at work.

It wasn't completely unredeeming, and I found some of the ideas intriguing, like the authors suggested division of labor and...more

like · see review

Jan 02, 2009 Tiago rated it 5 of 5 stars · review of another edition

I have read it as part of my PhD, since it's part of the classical books of software engineering. Yet the book tackles very important issues not only about management but how people interact during software development. I've recognised myself in many situations described by the author (even that I'm not part of a software development team).
One might wonder, as I did, how many of the concepts explained by the author apply to current technology of the 21st century, but the author tackles that in t...more

1 like · like · see review

Feb 09, 2012 Gregg rated it 5 of 5 stars · review of another edition

If I could only recommend one book on project management, The Mythical Man-Month would be that book.

I had an opportunity to hear Professor Brooks teach on the subject while he was writing the book and bought a copy as soon as it was released. That was shortly before I started my degree in CS...

I have found its advice invaluable in project management, not only for software projects, but just about any project I've ever been part of. And it presages many of the agile and small team development pro...more

like · see review

Mar 31, 2013 Rosa rated it 4 of 5 stars · review of another edition

Me siento culpable por no haber disfrutado much��simo con este libro, supuestamente uno de los grandes cl��sicos de mi profesi��n, que ha recibido montones de buenas cr��ticas y es un must read. Pero la verdad es que me ha resultado pesado y aburrido a veces, totalmente irrelevante en otras e incomprensible en bastantes... Obviamente lo he le��do teniendo en mente la cantidad de a��os que han pasado y esta edici��n en concreto tiene 4 nuevos cap��tulos escritos en el 20 aniversario que est��n mu...more

like · see review

Dec 03, 2012 Sander rated it 4 of 5 stars · review of another edition

This non-fiction work is filled with essays which focus on the project - management part of software engineering.

Very interesting if you work in software or in a PMO. These musings from the sixties and seventies are still a reality today. This book explains why adding man-months to a late project will make it later, why you can't seem to make the correct decissions.

You will be amazed how much you can learn in 2012 from this book, published in 1975. Recommended if you are interested in software....more

like · see review

Jun 02, 2012 Andy Love rated it 4 of 5 stars · review of another edition

Shelves: non-fiction

The classic book about software engineering, which reveals many of the secrets of the field - like "Adding more staff when a project is late, makes it more late" (hence the title) and "You may as well plan to throw the first design for a brand new system away - because you're going to have to do it anyway."

Also Brooks includes a passage from Heinlein's "The Man Who Sold the Moon" to illustrate the difference between the design lead and the administrative lead (or don't have your rocket designer...more

like · see review

Nov 16, 2010 Nick Black rated it 3 of 5 stars · review of another edition

Shelves: read-multiple-times, pimpin-aint-easy-but-computers-are

I give it three stars, but it probably deserves four -- several of the maxims herein have percolated into the wider community, and were known to me well before I first came across this. Brooks, by the way, has written more than this rather soft title -- his report on the IBM 360, for instance, is the first paper in Readings in Computer Architecture.

1 like · like · see review

Oct 07, 2012 Astro rated it 5 of 5 stars · review of another edition

A classic book for anyone around software development. It was written in 1974 -- basically a stone age as far as computers are concerned.

Some of the content is very current and applicable even today (and believe me, surprisingly lot of the stuff). Other chapters might be a little outdated here or there. But the most important message of this book is -- computers change, people don't. They were using virtually the same methodologies and dealt with very similar problems as we are today.

Amazing boo...more

like · see review

May 04, 2013 Vladyslav rated it 5 of 5 stars · review of another edition

Shelves: it

One can't simply go and write classic book about software development.

I came across this book long time ago somewhere in the end of high school. Later during university years I had an attempt to buy the book but skipped it in favor to some other programming book. At that time I made a promise to myself that I will read it one day. The day has come.
This is amazing how many people from IT industry heard about this book. I believe only legendary Donald E. Knuth series can compete with. And even...more

like · see review

Aug 25, 2010 Rick Toews is currently reading it

Shelves: programming, professional-development

The author received in 1999 the ACM's A. M. Turing Award, which, according to the back cover is "the most prestigious award in the computing field." He is cited for "landmark contributions to computer architecture, operating systems, and software engineering."

Chapter 1: The Tar Pit. In this chapter, I learned the distinction between a "program," a "programming product," a "programming system," and a "programming systems product."

The chapter describe the joys and the woes of programming, and I ca...more

like · see review

May 20, 2010 Nikolay rated it 4 of 5 stars · review of another edition

Ако се занимавате с правене на софтуер, задължително я прочетете. Наистина.

Аз я прочетох малко късно. Доста от нещата вътре или бях чувал или бях осъзнал по други пътища. Въпреки това беше поощрително и поучително да ги прочета накуп, описани с истински думи и то смилаемо.

Ако ще я четете, не се занимвайте с друго издание освен с най-новото (поне 20 години след първоначалното). В есетета примерите са ужасяващо остарели и дори някои принципни неща са се променили. В новото издание има допълнения к...more

like · see review

« previous 1 2 3 4 5 6 7 8 9 … 99 100 next »

new topic
Discuss This Book

There are no discussion topics on this book yet. Be the first to start one »

Recommend it | Stats | Recent status updates

combine
Other Editions (10)

More editions...

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »

Genres

Computer Science > Programming

141 users

Non Fiction

79 users

Computer Science > Software

59 users

Business

47 users

Science > Computer Science

40 users

Science > Technology

38 users

Computer Science > Computers

38 users

Computer Science > Technical

37 users

Science

10 users

Science > Engineering

9 users

See top shelves...

Readers also enjoyed similar books

Books by Frederick P. Brooks Jr.

The Design of Design: Essays from a Computer Scientist

Automatic Data Processing: System/360 Edition

More…

Share This Book

Facebook Twitter Your website

Trivia About The Mythical Man-...

No trivia or quizzes yet. Add some now »

Quotes from The Mythical Man-Month...

“A basic principle of data processing teaches the folly of trying to maintain independent files in synchonism.” — 3 people liked it

“As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.” — 2 people liked it

More quotes…

title link	preview: The Mythical Man-Month: Essays on Software Engineering
avg rating	preview: The Mythical Man-Month: Essays on Software Engineering Goodreads rating: 4.02 (2731 ratings)
small image	preview: click here [close]
med image	preview: click here [close]
BBCode	[url=http://www.goodreads.com/book/show/8967425-the-mythical-man-month?utm_medium=api&utm_source=blog_book][img]http://d.gr-assets.com/books/1355868379l/8967425.jpg[/img][/url] [url=http://www.goodreads.com/book/show/8967425-the-mythical-man-month?utm_medium=api&utm_source=blog_book]The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr.[/url]

The Mythical Man-Month: Essays on Software Engineering

Friend Reviews

Community Reviews

Goodreads is hiring!

Share This Book

Share This Book on Your Website