Goodreads helps you keep track of books you want to read.
Start by marking “The Mythical Man-Month: Essays on Software Engineering” as Want to Read:
The Mythical Man-Month: Essays on Software Engineering
Enlarge cover
Rate this book
Clear rating

The Mythical Man-Month: Essays on Software Engineering

4.03 of 5 stars 4.03  ·  rating details  ·  5,007 ratings  ·  327 reviews
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 projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive ...more
Paperback, Anniversary Edition, 322 pages
Published April 5th 2002 by Addison-Wesley Professional (first published December 1st 1974)
more details... edit details

Friend Reviews

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

Reader Q&A

To ask other readers questions about The Mythical Man-Month, please sign up.

Be the first to ask a question about The Mythical Man-Month

Community Reviews

(showing 1-30 of 3,000)
filter  |  sort: default (?)  |  rating details
Sondra Willhite
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
Igor Tsinman
The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks это уже классика. Все, кто хоть как-то связан с компютерами и/или проектами просто обязаны прочесть эту книгу. Заказчикам тоже не помешает узнать как все выглядит на самом деле.

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

В Израильслих стартапх эта книга хорошо известна, а выражение "Silver Bullet"
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
In this classic book on the software development process, Fred Brooks demolishes several persistent myths. They never quite go away: every new generation just has to learn them over again.

The first and most dangerous of these myths is the belief that putting more people on a project means it'll be completed more quickly. Brooks includes one of the most brilliant graphs I've ever seen, plotting number of women against time required to produce a baby. Would you believe it: the graph is flat at ni

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.
Rizky Januar
This famous and legendary book made me curious about what is inside it. This book tells about the nature of software development but mainly from the software project management perspective. Although it is an old book, primarily from the software projects happened in 1950's to 1970's, most of the content is still relevant in today's software projects. No matter what your role is (a programmer, an architect, a project manager, or a researcher), reading this book would benefit you. It gives you a b ...more
Even for an inexperienced undergraduate student like me, this book made a lasting impression and left me pondering on the various human dynamics involved in software engineering. Definitely a must-read.

Warning: It does get a little dry at times, and most of the examples are very outdated,but the principles explained are timeless.
Książka o zarządzaniu projektami IT napisana... 40 lat temu. Przerażające jest to, jak bardzo jest aktualna - wiele problemów opisywanych przez Brooksa nie zniknęło do dzisiaj, a techniki radzenia sobie z nimi są nadal stosowane (choć często pod innymi nazwami).
Oczywiście nie da się ukryć, że sporo informacji w książce jest już bardzo przestarzała (developer powinien tak przygotować program na kartce, by nie zabierać cennego czasu na współdzielonej maszynie; pojawia się "nowatorskie" podejście
Duong Tan
Năm 1995, trong lời bạt cho lần tái bản kỉ niệm 20 năm xuất bản “The Mythical Man-Month”, tác giả Fred Brooks khẳng định những nhận định cơ bản trong cuốn sách vẫn còn nguyên tính thời sự. Hơn một thập kỉ sau, Mary Poppendieck nhắc lại “Một cuốn sách kinh điển đã trụ vững qua thời gian. Điều đó cho thấy có rất ít thay đổi trong suốt 30 năm qua”. Có lẽ đó là lời gợi mở hữu ích để chúng ta lật giở những trang sách đáng quý, và suy ngẫm xem liệu những nhà quản trị dự án có đang đi lại những vết xe ...more
Interesting book with a pretty narrow focus, a collection of essays on the management and planning of good software engineering. The author instilled the mistakes and successes of his work on the IBM 360 Operating System in the 70s, and most of what he found still applies today. For example, wisdom like: more programmers make a project only late, and if you add programmers to an already late project, results will arrive even later. Have an architect and a manager, hopefully in two different pers ...more
Nov 23, 2011 Joecolelife rated it 5 of 5 stars
Recommended to Joecolelife by:
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

* 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
Kristofer Carlson
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
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
Nick Black
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.
Narendran Thangarajan
I had underestimated the applicability of the ideas presented in the book since it was originally published in 1975. Dr. Brooks presents a set of essays on software engineering based on his experiences and the lessons he had learnt while developing the System/360 and OS/360 for IBM in the early 1960's. It is interesting to note that the technical and managerial challenges he faced back then are still very relevant despite the exponential improvement in the technical tools we employ to solve thes ...more
Nathan Glenn
I probably should re-read this when I have more experience working on software teams. Right now, I don't have much of a basis to apply the content to.
The author describes the lessons he learned working on an operating system in the 1960's, and the problems of organizing a thousand engineers to deliver software on time and maintain it afterward remain relevant. The most well-known insight is that large teams take longer to complete software because of the increased need for constant communicatio
Shawn Morel
Read it for the first 2 chapters - they are unbelievably insightful and still relevant to modern software development. The rest of the book was very much a prescription of actionable items at the time and shows it's age. The tools, people, teams and times have changed.
Jason Benn
Hasn't aged too well, unfortunately. A lotta shit's gone down since 1975. Nevertheless, here are some of my favorite ideas:
--build prototypes and throw them away before embarking on large projects,
--actual coding is only responsible for 1/6th of actual dev time (1/3 should be spent on design, and 1/2 will be spent on debugging and testing),
--when you're building a big app, ideological consistency is the most important factor in reducing complexity, and this can be accomplished by having one or t
Matt Jackson
I'm sure this book was revolutionary 30 years ago, but is pretty mediocre by today's standards. There are still some gems to be found inside, but most of it reeks of outdated enterprise project management.
Alexander Yakushev
Some of the ideas in the book are out of date, some apply only to really big projects; but I would certainly revisit this piece if I was to design a big software system from scratch.
Koen Crolla
The Mythical Man-Month is by no means the worst book to be elevated to the programmer canon, but 1975 was a long, long time ago. It's rife with anachronisms† and ill-advised predictions, none of which were excised in the 1995 revision.‡
Other issues are more contentious: Brooks is married to proprietary software written for shitty environments, and a lot of problems he sees just don't exist for decent people. For example, he believes a computer program should have three levels of documentation: o
Trevor Vass
This was the first book I read when taking a job with a project management component for a software development team. My boss at the time recommended it as one of the best books to introduce how software project management was different from traditional project management. He was right, applying the principles in this book helped me to better support my team via resource allocation and planning. I would highly recommend this to anyone entering the software development field, whether as a project ...more
فاروق الفرشيشي
I feel proud to read the mythical Mythical Man-Month. First published in 1975, most of the chapters become obsolete by now, the examples used become incomprehensible in this era, young software people have never dealt with OS/360 which is the main reference project used in the book. But, what the MM-M loses in software field gained it in History one. If there's a field of study such as Software History, this book would be a reference in the kind.
I may agree with Brook's theory about the Mythical
Paul Weinstein
Two suggestions for those considering reading this book near the 20th anniversary of this 20th anniversary edition:

1) This book is a collection of essays written over the course of a 40 year career. While it required the author to procede in sequential order, it does not require the reader to do so.

Therefore, a useful suggestion might be to read the last two "chapters" first and then proceeding however one wishes from there. Propositions of The Mythical Man Month (chapter 18 in the anniversary
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
Cody Ray
Like most people, I picked up The Mythical Man-Month simply because its a classic in the software engineering field. As a book on computing written in the 70s, it has a lot of out-of-date content and confusing terms ("architect" refers to the person gathering the user requirements, "producer" refers to a project manager, etc) . However, there were several essays that are still very relevant (or at least thought-provoking) today and these make the book worth reading. Much of the book was assemble ...more
Barney Trotwell
The Mythical Mythical Man-Month.

This book is definitely dated, and I bet that's one of the sources of my frustration for it.

Another is its romantic outlook. It starts by telling you, the programmer, why you love programming, because apparently the author knows. And what he says is how programming is pure thought put into action, just like God's word created the World. I bet I'm misquoting, but it doesn't matter much.

Later on, the author talks about phenomena that he has noticed in the process
Dan Cohen
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
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
« previous 1 3 4 5 6 7 8 9 99 100 next »
There are no discussion topics on this book yet. Be the first to start one »
  • Peopleware: Productive Projects and Teams
  • Code Complete
  • Programming Pearls
  • Refactoring: Improving the Design of Existing Code
  • Joel on Software
  • The Practice of Programming
  • The Pragmatic Programmer: From Journeyman to Master
  • Working Effectively with Legacy Code
  • Design Patterns: Elements of Reusable Object-Oriented Software
  • Test Driven Development: By Example
  • Death March
  • Facts and Fallacies of Software Engineering
  • Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)
  • Domain-Driven Design: Tackling Complexity in the Heart of Software
  • Beautiful Code: Leading Programmers Explain How They Think
  • Compilers: Principles, Techniques, and Tools
  • Clean Code: A Handbook of Agile Software Craftsmanship
  • Refactoring to Patterns

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »
The Design of Design: Essays from a Computer Scientist Automatic Data Processing: System/360 Edition Ningetsu No Shinwa Computer Architecture Concepts and Evolution

Share This Book

“A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too.” 5 likes
“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.” 4 likes
More quotes…