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:

Other editions

Enlarge cover

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

Open Preview

The Mythical Man-Month: Essays on Software Engineering

Frederick P. Brooks Jr.

4.05 · Rating details · 9,809 ratings · 645 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

Get A Copy

Or buy for

Paperback, Anniversary Edition, 322 pages

Published August 12th 1995 by Addison-Wesley Professional (first published 1975)

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.

Lists with This Book

The C Programming Language by Brian W. Kernighan

Essential Programming Books

152 books — 448 voters

Introduction to Algorithms by Thomas H. Cormen

Structure and Interpretation of Computer Programs by Harold Abelson

The Art of Computer Programming, Volumes 1-3 Boxed Set by Donald Ervin Knuth

Essential Books of Computer Science

170 books — 226 voters

More lists with this book...

Community Reviews

Showing 1-30

4.05 ·

Rating details

· 9,809 ratings · 645 reviews

Filter

Sort order

Dec 09, 2009 Manny rated it it was amazing

Shelves: linguistics-and-philosophy

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 ...more

flag 33 likes · Like · see review

Oct 01, 2011 Jan-Maat added it

Shelves: 20th-century, business-management-pm, thinking

Since what I know about programming probably could be written on the back of a postcard and wouldn't be worth reading there's nothing worthwhile that I can say about the software engineering side of this collection of essays about software engineering.

Further Brooks was writing in the 60s, in part based on experience from the 50s, which I suppose means I'll be making some claim to wider applicability with regard to project management & people management and understanding the nature of tasks. ...more

flag 21 likes · Like · see review

Oct 17, 2016 David Bjelland rated it liked it

Shelves: cs-software

As far as I can tell, the core tenets of this book aren't really even up for dispute anymore. I don't mean to sound like the grumpy reader mentioned in the epilogue, complaining that the book offered "nothing I didn't know already know" (however experienced he might have been, I still doubt it), but whether from my limited experience in the industry first hand or second-hand through the various managers I've had over the years, the tenet that developers and time aren't interchangeable resources As far as I can tell, the core tenets of this book aren't really even up for dispute anymore. I don't mean to sound like the grumpy reader mentioned in the epilogue, complaining that the book offered "nothing I didn't know already know" (however experienced he might have been, I still doubt it), but whether from my limited experience in the industry first hand or second-hand through the various managers I've had over the years, the tenet that developers and time aren't interchangeable resources felt both familiar and self-evident. So, in a certain sense, I don't feel like I have any more business critiquing this as a book than I do "Relativity: The Special and General Theory." Still, another part of my brain is content to separate a critique of the book qua book from any kind of dispute with the actual arguments and share some petty little snipes that made this less enjoyable of a read than it could have been:

1) His stubborn refusal to ever acknowledge the reality of female programmers.

This frustrating trend starts with the title (what the hell is a "man"-month? Does your project need beards to get grown or code to get written?) and just never. Lets. Up. Except for a grammatically-necessary "she" when mentioning Frances Spence (on the final page!), I'm not sure that female pronouns show up once in this entire book. Sure, "they" didn't have the same legitimacy as a gender-neutral singular pronoun then that it does today, but this thing was reissued in 1995, a time when "they" might have been cutting edge, but "he or she" was standard practice even in elementary school grammar. It's not just developers either - system architects, managers, everyone on the "surgical team"; hell, even USERS, at least the ones with any amount of initiative in testing the limits of the software, are all male by default.

Wait, I just remembered - women DO come up. To paraphrase: "you can't make nine women pregnant and expect a baby in a month."

Ugh.

I'm sure this isn't a new point to make, and I'm sure he's responded with grace and candor about how the standard of writing he grew up with used male pronouns as a convenience to refer to EVERYONE, and of COURSE he's had the pleasure of working with plenty of competent, even visionary women throughout the years, and such and such and such. If making the original text even a little bit gender inclusive was an innocent oversight on Brooks' part, his editor for the reissue gets less of a free pass. Women code. As a courtesy to them, please update your grammar.

2) The gratuitous religious overtones

Don't get me wrong - I still vividly remember the almost spiritual ecstasy of that first day when I really "got" recursion, and I completely understand how someone might position the beauty of software design within their existing framework of spirituality, Christianity. Unfortunately, a consequence of building your whole cosmology around a being like the Western monotheistic God is that it necessarily consumes anything and everything else; it then becomes almost impossible to write about the beauty or nobility of some pursuit or principle except to the extent that it supposedly emanates from the nature of this supposed entity. A connection between good software design and Christian ideas of holiness pop up again and again, and they grate on me not just because they come across as a bit sanctimonious, but because oftentimes, the Christian lens actually distorts the content.

Two examples spring to mind: the first comes in the chapter "Aristocracy, Democracy, and System Design", which argues for conceptual integrity as the supreme virtue of a software system. I'll grant that the book predates all of the advances that made true open-source systems possible or the achievement of GNU/Linux to prove it was a viable model, but Brooks seems so wrapped up in the analogy of the God-like software architect that he never gives the heathen "bazaar" model fair consideration - the "cathedral" is self-evidently superior to anyone who sincerely believes the entire world represents a unified, intentional design by a single entity.

The second is in the chapter "Why Did the Tower of Babel Fail?", and my objection boils down to this: the Tower of Babel didn't fail because the builders "lacked organization and communication." It failed because an omnipotent being intervened to make it impossible to have organization and communication; this happened, in turn, because the Christian God (and especially the Old Testament God) is an angry, spiteful, and sometimes downright petty being, and that the organized human enterprise of building this tower represented a challenge to his authority. The interpretation Brooks chose to go with confuses proximate and final causes, which made it hard for me to buy any of what followed, no matter how legitimate the points themselves might have been. ...more

flag 17 likes · Like · see review

Dec 05, 2015 Daria rated it it was ok

Except blatant sexism* it was a pretty good book. It's a series of experiences that you gradually pick up when you're working in the software industry. It's a little outdated, e.g. we don't have printed manuals anymore and we don't have to deal with the woes of constantly updating them, but a lot of wisdoms from this book are still valuable.

* the entire book never uses a female pronoun. ever. it makes it sound like engineers, managers, technical leads, clients are always only male. plus there's ...more

flag 15 likes · Like · see review

Apr 03, 2016 Pratul Kalia rated it it was amazing · review of another edition

I want to print many copies of this book.
I want to print many copies and roll them up.
I want to roll them up and take them to meetings with my clients.
I want to take them to meetings and hit them over the head repeatedly while screaming "more... than... 30... years... and you... still... don't... understand... anything... stop... making... me... write... bad... software...!"

Seriously.

flag 17 likes · Like · see review

Apr 16, 2018 Brian Yahn rated it liked it

The Mythical Man-Month starts of strong--with a solid mix of good humor, great story-telling, and even better analogies and metaphors. Most interesting, the claims Frederick Brooks made more than 40 years ago remain true today. But even so, the book has not aged well.

Chapters 5-8 and 9-15 seem wildly out of date. I give some reasoning below, but the gist is that the middle is mostly skippable. Worse is that the religious overtones get a little out of hand in this section. And to make it even mor The Mythical Man-Month starts of strong--with a solid mix of good humor, great story-telling, and even better analogies and metaphors. Most interesting, the claims Frederick Brooks made more than 40 years ago remain true today. But even so, the book has not aged well.

Chapters 5-8 and 9-15 seem wildly out of date. I give some reasoning below, but the gist is that the middle is mostly skippable. Worse is that the religious overtones get a little out of hand in this section. And to make it even more obvious how out-dated it is, the sexism is rampant--where Brooks intentionally uses "he" for every pronoun. Granted, nearly all programmers were males at the time, so it's not like his usage is misleading. But reading it in this age, it feels like the book intends to be sexist.

Questionable pronoun usage aside, the first four chapters, chapter 7, and the final chapters are still really insightful. They mostly detail how and why software development costs so much (even today), and why adding more engineers to a project is unlikely to speed productivity linearly.

The key take-away is that the biggest problems in software development stem from 1) communication and organization, and 2) managing added complexity. In some ways, I think I always knew this. But the chapters articulated it very clearly and convincingly.

It makes me wonder why engineering interviews select so much for problem-solving and hardly at all for communication and organization skills, or the ability to manage growing complexity.

I'd highly recommend chapters 1-4, 7, and 16+. Here's a summary of why I'd skip the rest:

Chapter 5 can be summed up with Ernest Hemingway's famous quote: "The first draft of everything is shit." Brooks gives some detailed explanations about why the first draft of every program is shit, and how to prepare for that and design around it. Chapter 11 mostly re-iterates this.

Chapter 6 describes how cumbersome the OS/360 manual became. Although insightful--because of how laughably out of date it is--manuals have mostly been replaced with auto-generated websites. But back in the days of OS/360, when engineers first arrived at work, a stack of pages would be waiting at their desk. These pages represented the changes made to the system in the previous day, and the engineer was supposed to find the pages in the FIVE-FOOT-TALL manual and replace them with these new pages. Brooks chronicles the problems of maintaining such a manual, and how switching to a microfiche manual helped in some ways, but hindered in others.

Chapter 10 talks about important documents for a software organization. While these might hold relevance in a major enterprise-y setting, they seemed pretty out-of-place in a startup environment.

Chapter 13 explains the properties of a good testing framework, basically preaching the importance of unit tests and integration tests. This is taken for granted in the modern work-place as every company at least knows of the importance.

Chapter 14 similarly explains the importance of milestones, or major goals with clearly discernible and verifiable endpoints. Again, this is taken for granted in the modern work-place. Kanban, Agile, and every other Software Development Life Cycle mostly revolves around this.

Chapter 15 spells out the importance of documentation. But peering into the future, Brooks sees this becoming obsolete, admitting that newer languages of the time, like Ada, allowed for code to be almost human readable. Nowadays, code is human readable enough that most programmers prefer for code to be "self-documenting". It's always up for debate if the code written is in fact self-documenting. But the importance of documentation is constantly diminishing as languages become ever-more declarative, and systems are better and better designed. ...more

flag 9 likes · Like · see review

May 01, 2011 Igor Tsinman rated it it was amazing

Shelves: programming, the-best

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

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

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

flag 8 likes · Like · see review

Nov 01, 2009 Graham rated it really liked it

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 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. ...more

flag 8 likes · Like · see review

Apr 10, 2017 Dorin rated it it was ok · review of another edition

I was underwhelmed with how badly this text has aged. The references, which made sense 15 years ago, no longer hold water, and the most-referenced-project is certainly no longer the way we write software nowadays. While the idea remains valid, I think people writing about this text are more relevant than the text itself, holding only historical value, at most.

flag 4 likes · Like · see review

Dec 06, 2018 Bill rated it it was amazing

Shelves: dev-reading-list, peopleware, tech-lead

I re-read this recently after recommending it to a colleague, mainly just for nostalgia and planning to read a few of the more popular essays, like "The Tar Pit." Instead I read the entire book again and still found it fresh and insightful, over 40 years since publication. The prose manages to be dense with ideas but brilliantly clear and often witty. Now as I read contemporary writing (blogs but even books), I deeply lament this lost art.

Aside from his bold statements, most famously Brooks' Law I re-read this recently after recommending it to a colleague, mainly just for nostalgia and planning to read a few of the more popular essays, like "The Tar Pit." Instead I read the entire book again and still found it fresh and insightful, over 40 years since publication. The prose manages to be dense with ideas but brilliantly clear and often witty. Now as I read contemporary writing (blogs but even books), I deeply lament this lost art.

Aside from his bold statements, most famously Brooks' Law, that have been cited to the point of cliche, what struck me most this time around is how much his enthusiasm for building systems and leading teams comes through. You'd expect a grizzled veteran of massive IBM projects to be somewhat jaded, but personally I found his descriptions of what builders love about building to be quite beautiful. If I am half as enamored with my craft at his age, I'll feel lucky.

IMHO this ranks right up alongside Peopleware and Psychology of Computer Programming as absolutely essential reading for technical leaders. The specific references, even from the 2oth anniversary section, are dated (MS Works fans out there?) but 80% of the points made haven't aged a day. If anything, the obsolete sections will be a sobering reminder that your Macbook is basically a supercomputer you can bring on the train for your own exclusive use. I'm so thankful I no longer have to worry about the size of my functions in memory and can use beautiful, interpreted languages like Ruby at web scale, for example to run this website ;-)

Some reviewers have noted the exclusionary language of only male pronouns. There were actually far more women programmers in 1975 (before the PC era), so I have to assume this is purely a stodgy style convention (and was not used in the 1995 add-on chapters). And yes there are some religious undertones scattered throughout but they didn't get in the way of the ideas for me.

Highly, highly recommended. A great book to read with your team to share war stories. ...more

flag 3 likes · Like · see review

Apr 03, 2019 Nente rated it liked it

Shelves: nonfiction, read-original

This is more of historical importance than a go-to book nowadays. Still, I'm glad to have read it.

I agree with the points made in these two reviews, especially the ones about the default male programmer and the overextended Christian viewpoint, which actually makes Brooks misstate one of his examples.

Still, I loved the positive and realistic message of "There is no royal road, but there is a road." I can stand behind both parts of this one.

flag 3 likes · Like · see review

Mar 06, 2014 Duong Tan rated it it was amazing

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 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 đổ đã được chỉ ra từ hàng thập kỉ trước hay không.

Thú thật, cho tới giờ tôi vẫn thấy rất khó chịu khi phải làm việc với những trang dự án bắt buộc phải ước tính ra bao nhiêu Man-Month (hay dùng đơn vị khác là “ngày-công”), mặc dù biết rất rõ những ước lượng kiểu này chỉ để mà … ước lượng. Còn đây là lời của Brooks hơn 40 năm trước: “Man và Month (hay con người và thời gian) không để hoán đổi, cẩn thận với khái niệm Man-Month. Thêm người vào dự án chậm tiến độ chỉ làm chậm tiến độ thêm mà thôi”. Thời điểm đó có thể có người còn chưa đồng ý, nhưng ngày nay thì cái được biết đến với tên “Định luật Brooks” này đã được khá nhiều nhà quản trị dự án quán triệt rất kĩ.

Mặc dù tập trung vào những vấn đề liên quan tới con người trong việc quản lí dự án phần mềm, Brooks đã đi xa hơn rất nhiều để thảo luận kĩ về những vấn đề liên quan đến công cụ, phương pháp, quy trình hay tổ chức để tìm kiếm một sự hiểu biết thấu đáo và đầy đủ trong lĩnh vực quản trị dự án và phát triển phần mềm. “The Mythical Man-Month” trở thành kinh điển có lẽ bởi người đọc nó không chỉ có được một cái nhìn toàn cảnh, mà còn là cái nhìn rất sâu sắc vượt thời gian của một người giàu kinh nghiệm trong ngành. Mỗi một lần đọc lại, tư duy của người đọc như một lần được làm mới.

Đối với những người thực hành Agile, đây là một cuốn sách tham khảo hết sức quan trọng. Từ trước thập kỉ của Agile rất lâu, Brooks đã dùng tư biện để đưa ra những nhận định không khác gì so với những gì được thể hiện trong Manifesto (tuyên ngôn) và các nguyên lí của Agile:

Con người quyết định tất cả, công cụ chỉ là cái phục vụ cho con người thực hiện tốt hơn công việc của mình (Agile Manifesto nói: cá nhân và tương tác hơn là quy trình và công cụ”)
Man và Month (hay con người và thời gian) không để hoán đổi, cần cẩn thận trong việc dùng Man-Month làm độ đo để ước tính và lập kế hoạch (Agile tránh ước lượng ra MM một cách cứng nhắc, mà tập trung vào các kĩ thuật thích ứng – adaptive - trong lập kế hoạch).
Conceptual Integrity: tính toàn vẹn khái niệm là trung tâm của vấn đề chất lượng (Agile và Lean gọi nó là chất-lượng-tự-thân, hay là “toàn vẹn tự thân”)
No Silver Bullet: không một quy trình tuyệt hảo nào có thể gia tăng ngay lập tức năng suất lao động của lập trình viên (Agile đề cao tính linh hoạt, thích ứng và tùy biến để phù hợp với các điều kiện thực tế, năng suất của nhóm được cải thiện thông qua quá trình thích ứng, học tập và cải tiến liên tục)
Incremental Build (xây dựng tăng trưởng) thì tốt hơn (Agile: tăng trưởng và lặp)
Trao quyền và phi tập trung hóa (Agile gọi cơ chế này bằng những khái niệm nhóm tự-tổ-chức và liên-chức-năng)
Mô hình Waterfall sai rồi! (chỉ rõ Man-Month là mythical, thì hệ quả tất yếu là mệnh đề này)
Đặc điểm dở nhất của cuốn sách có lẽ là nó đã lùi hơi xa vào quá khứ, khi mà nền công nghệ thông tin khác khá xa so với ngày nay, những vấn đề kĩ thuật cụ thể có thể đã không còn gần gũi với bạn đọc của thế kỉ XXI. Có vẻ nó hơi khó đọc. Nhưng như thế lại càng làm nổi bật rõ những chân lí xuyên thời gian, không phụ thuộc bối cảnh hay nền tảng công nghệ, qua đó ta có thể rút ra được những bài học bổ ích. Vì vậy mà một cuốn sách gần 40 tuổi này (xuất bản lần đầu năm 1975) không chỉ là tập tài liệu đọc thêm bắt buộc của sinh viên ngành Software Engineering, mà còn được những nhà quản trị dự án phần mềm chọn làm sách gối đầu giường. ...more

flag 3 likes · Like · see review

Dec 29, 2015 Matt Diephouse rated it liked it

I'm really surprised that people still recommend this book. It's primarily concerned with very large scale software projects (i.e., an operating system), much of the "data" is anecdotal, and many of the assumptions are simply outdated. For instance, Brooks writes about (1) creating paper manuals with documentation about the system that get updated daily for the engineers, (2) strategies for time-allocation on centralized computers, and (3) about optimizing for compiled code size. Those simply ar ...more

flag 3 likes · Like · see review

Aug 07, 2012 Philipp rated it really liked it

Shelves: non-fiction, programming

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

flag 3 likes · Like · see review

Oct 03, 2015 James Oden rated it it was ok

Shelves: computer

Many times when I read a book that is dated, its pearls of wisdom are still there in clear view to be harvested and made use of. I can't say the same thing about the Mythical Man Month. I will grant that Brook's Law still holds, and managers still today stumble over this one. However much of his advice fell flat in the face of the more recent agile development movement and still more recent devops movement. In the end he was still preaching a kind of waterfall type approach to development which ...more

flag 3 likes · Like · see review

Feb 16, 2016 Nikos Karagiannakis rated it it was amazing

Shelves: in-bookshelf

Ο εκδοτικός οίκος ζήτησε από τον συγγραφέα να μην αλλάξει τίποτα από το αρχικό κείμενο και, επιπλέον, να προσθέσει 4 νέα κεφάλαια.

Στα τελευταία κεφάλαια, ο συγγραφέας κάνει έναν απολογισμό των συμπερασμάτων της αρχικής έκδοσης (1974) σε σχέση με το τι ισχύει την εποχή της επετειακής αυτής έκδοσης (1995).

Η τεχνολογία των αρχικών κεφαλαίων φαντάζει από παλιά και άκρως ενδιαφέρουσα (όπως θα έλεγε κάποιος, σαν εμένα, που ο πρώτος του υπολογιστής ήταν ένα Sinclair ZX81) έως προϊστορική (όπως θα έλεγε ...more

flag 3 likes · Like · see review

May 12, 2011 Megha rated it liked it

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.

flag 3 likes · Like · see review

Apr 18, 2010 Mouly rated it it was amazing

* 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

flag 2 likes · Like · see review

Jan 31, 2016 Joan rated it liked it · review of another edition

Fascinating series of essays about building software and managing teams. Some bits really resonated, especially about the craft of software engineering. Brooks said that the hardest part about learning to program is adjusting to the necessity of perfection, which I think is still true today. He also had the most apt description of what it feels like to actually write code, and the differences between the essential work of building software and the "accidental" work imposed by poor tools, process ...more

flag 2 likes · Like · see review

May 23, 2012 Senthil Kumaran rated it it was amazing

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

flag 2 likes · Like · see review

May 14, 2016 Jim rated it it was amazing

Everybody should read this book, not just programmers or project managers. It's easy and fun. There are 9 chapters, but you only need to read 3 of them. You'll know which ones. When he starts slinging equations, skip over those parts. He uses cooking metaphors where most software books use building construction metaphors. The unconscious gender bias, typical of the time, is almost funny. He keeps saying how many "men" does it take to do a project.

I'm frequently surprised at how many software pro ...more

flag 2 likes · Like · see review

Jan 02, 2009 Tiago rated it it was amazing

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

flag 2 likes · Like · see review

Sep 12, 2017 John Mehrman rated it it was amazing

Originally written in 1975, prior to the PC explosion in the mid-1980s, Brooks book is still relevant today. The same systems management "rules-of-thumb" and potential pitfalls still exist in largely the same form. Many of his bigger lessons expand beyond just software development and apply to program management as a whole. A must read for anyone in that develops complex systems.

flag 2 likes · Like · see review

Nov 07, 2011 Shyam rated it really liked it

Shelves: tech-books

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.

flag 2 likes · Like · see review

May 28, 2017 ABC rated it it was amazing

I just leave my rating at here and dont say anyfuckinthing.

flag 2 likes · Like · see review

Feb 03, 2018 Amy Jones rated it liked it

So much of this book is quaint. The descriptions of documentation that needs to be printed out to be shared, computer systems that can barely run the programs that are being built...with all of the technical advances, you’d think we’d be further along in our understanding of how to build this stuff. O the contrary, teams still fall subject to the same issues that are described and the advice given is just as applicable.

flag 1 like · Like · see review

Feb 10, 2018 Ondrej rated it liked it · review of another edition

First part of the book is the original from 1975. Most of the general ideas listed by the author are interesting, but he's focusing on very large teams (developing operating systems, compilers etc) working with now very outdated technology, solving very different set of problems. Luckily, it was quite short. 2/5.

Second part of the book is a summary of the original book and reflections of the author after 20 years. This was much easier to read since thoughts from 1995 are more relatable. After ge ...more

flag 1 like · Like · see review

Jan 19, 2018 Alison Rowland rated it liked it · review of another edition

Obviously, this is a classic. However, it's so much a classic, that I think most of its ideas have already entered into modern software engineering practices. I ended up skimming a lot of this.

flag 1 like · Like · see review

Apr 03, 2019 Ashish rated it it was amazing

A very insightful book on how to approach software development. This book has few gems which stay with you for the result of your life.

flag 1 like · Like · see review

Feb 05, 2019 Irio rated it it was amazing

The best book I’ve read in software project management is from 1975.

flag 1 like · Like · see review

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

new topic
Discuss This Book

topics	posts	views	last activity
Edb mailboxes converter in PST format	1	3	Oct 19, 2018 10:36PM
Malwarebytes Input/Output errors in the scan report	1	1	Sep 03, 2018 01:20AM
QuickBooks Error Code 6189 – How to Fix this Error	1	2	Apr 10, 2018 12:24AM
Read Online Software Engineering (10th Edition) Ebook DOWNLOAD	1	3	Dec 28, 2017 07:01AM

Readers Also Enjoyed

Goodreads is hiring!

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

Videos About This Book

Add a comment

About Frederick P. Brooks Jr.

Frederick P. Brooks Jr.

46 followers

Books by Frederick P. Brooks Jr.

The Design of Design: Essays from a Computer Scientist

Automatic Data Processing: System/360 Edition

Computer Architecture: Concepts and Evolution

More…

Trivia About The Mythical Man-...

No trivia or quizzes yet. Add some now »

Quotes from The Mythical Man-...

“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.” — 9 likes

“Adding manpower to a late software project, makes it later.” — 9 likes

More quotes…