Read The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr. Online


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 massiveFew 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 software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."...

Title : The Mythical Man-Month: Essays on Software Engineering
Author :
Rating :
ISBN : 9780201835953
Format Type : Paperback
Number of Pages : 322 Pages
Status : Available For Download
Last checked : 21 Minutes ago!

The Mythical Man-Month: Essays on Software Engineering Reviews

  • Manny
    2019-03-18 05:55

    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 nine months, irrespective of how many women are assigned to the project. As he points out, software development is often remarkably similar.If you're a young software developer and were at all surprised by the above, you should get hold of a copy of Brooks without delay. A few of his observations may now be a little dated, but most of it is still pretty damn relevant.

  • Jan-Maat
    2019-03-13 05:00

    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.I read the 20th anniversary edition, which I recall as not cheap and to justify the price is expansively laid out with lots of black and white picture of prehistoric beasts caught in a Tar pit, the Tower of Babel, werewolves and other such things that leap to mind as metaphors to explain the experience of certain projects, there isn't one of a burning Zeppelin, but perhaps that will be rectified in a future edition.I'll proceed with brief summaries of the essays:The Tar Pit ?The Mythical Man Month - if a project is late, adding additional manpower will only delay it further, particularly if the nature of the project requires communication between team members.The surgical Team a project team is best organised with fixed and exclusive roles each member focused on one task - like a surgical team, this approach is scalable if a large project can be sliced up into appropriate chunksAristocracy, Democracy, & System design Be like the Cathedral builders of Rheims, accept the creativity of implementing somebody else's vision to achieve greatest over all harmonyThe Second System effectDesigner of their first system will be feeling their way, and so cautious and lean, their second system tends then to filled with baroque detailing and pet ideas.passing the word I think that was about project documentationWhy did the Tower of Babel Fallcommunication problems, also, don't vex God unnecessarily.Calling the Shot ?ten pounds in a five pound sack ?The documentary hypothesis plan to throw one away more or less what it says sharp tools meh ,computer stuff, those things will never catch on. the whole and the parts as above, and get off my lawnhatching a catastrophe "How does a project get to be a year late?..One day at a time"(p.246) the other face ? no silver bullet good news for Werewolves, there are no silver bullets.Then the main points are repeated in brief pp230-250 obviating the need for the rest of the book.I had dog-eared a couple of pages in the No Silver Bullet chapter the first time I read it but it was another person who read it and I couldn't see or imagine what had caught his attention then. I'm dead to myself apparently!The above possibly sounds rather grudging particularly the chapters which seemed too vapid to deserve anything more than a question mark. Yet I found this book very exciting the first time round (and not just on account of the picture of prehistoric mega fauna caught in a tarpit). For this there are two reasons. Firstly as he acknowledges it is a book about software programming and so its theme is people working in teams to deliver a service product for end users, he happened to be familiar with software but my second reason is that this is a wisdom book and that wisdom is widely applicable - any organisation delivering a produce or service to end users (who may or may not be the people paying). Plainly the downside to a wisdom text is that it is apocryphal (view spoiler)[ ie anecdotal and derivative(hide spoiler)] but I'm old enough and ugly enough to live with that indeed as with wisdom literature I found it as much reassuring as instructive. I had noticed that adding people to the late project no more speeds delivery than the addition of extra women to assist in a pregnancy, but I wouldn't have dared admit it counter to the orthodoxy around me. Indeed the additional labour not only caused me extra work but brought me to tears. Brooks approvingly cites others writers (pp276-7) that the nature of work is not technological but sociological, hence, perhaps, the lasting appeal of working for yourself.Also is point about end users influenced my thinking he says that point of programming is not to make a program that can do something or other but to satisfy the user (view spoiler)[ or the purchaser, not necessarily the same person (hide spoiler)] which for me was quite a paradigm shift from providing a definable technical service to customer satisfaction and indeed one can nuance that particularly if thinking about public services were you have multiple parties expecting different outputs of a services.So possibly I can not in fairness recommend this book widely the fruits I plucked from it may not appeal to the tastes of others, indeed you may not find anything new or tasty there particularly if you are a thoughtful anthropologist of the workplace.On software his championing of the thrice noble microfiche maybe too quaint for contemporary taste, and generally for all readers all workers in this book and all presumed workers, united, all round the world, are men, which for somebody who was working not just in the 50s but into the 70s and 80s, strikes me as interestingly thoughtless.

  • David Bjelland
    2019-02-25 06:13

    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 overtonesDon'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.

  • Igor Tsinman
    2019-02-25 04:09

    The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks это уже классика. Все, кто хоть как-то связан с компютерами и/или проектами просто обязаны прочесть эту книгу. Заказчикам тоже не помешает узнать как все выглядит на самом деле.The Mythical Man-Month это кладезь, хорошо изложеных замечаний, идей, рекомендаций и еще масса прочего полезного материала. 100 процентов идей Брукса актуальны сегодня!!!В Израильслих стартапх эта книга хорошо известна, а выражение "Silver Bullet" стало нарицательным и его знают даже те, кто не прочел книгу Брукса)))Вот пример: парадигма Бруксаговорит о том, что oбмануть жизнь не удасться (звучит знакомо, а для некоторых и грустно) Т.е. есть только один реальный способ завершить проект - это инкрементальное развитие, при котором маленькие части регулярно интегрируются в работающий проект. Для тех кто в танке поясню на таком примере: вас не спасет замена С++ на JAVA-JAVA/C#, вам не поможет покупка супер-пупер крутого CMS, даже недавно нанятый варяг-супер-программер не вытащит ваш проект.Silver Bullet это миф, который активно поддерживается/культивируется менеджерами-растяпами или рвачами, охочими до дармовых средст/баджетов. Все просто, но как говор ят винтернетах: "Мыши плакали и кололись, но продолжали упорно жрать кактус".Еще один интересный аспект, который доходчиво рассматривает дедушка Брукс это крутизна архитекторов/дизайнеров/программеров. Его теза проста: крутые в 10 раз продуктивнее и полезнее (для бизнеса), чем хорошие (принцип 80-20 гласит, что 20% людей делают 80% работы. Недавно выяснилось, что 80% людей считают, что они входят в эти 20%))). Это заявление очень раздражает девочек из отдела кадров (ну, типа у нас все замечательные и хорошие). Еще это не нравится большим начальникам, ибо если с этим положением согласится, то сразу же поднимается вопрос о зарплатах этих самых крутых))). Даже анекдот про них сочинили: Распоряжение начальника:Каждому программисту сотруднику в офисе предоставить пульт с двумя надписями:- кофе- минетУ хороших сотрудников - это кнопки, у плохих - лампочки.Вот так и живем! Я отношу книгу The Mythical Man-Month к разряду the best and must read. Period!

  • Daria
    2019-02-18 10:07

    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 this:'A team of two,with one leader , is often the best use of minds. [Note God's plan for marriage.]' Did you really have to include your conservative outdated patriarchal views in a non-fiction book about computer science?

  • Graham
    2019-02-25 06:23

    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.

  • Pratul
    2019-03-04 10:14

    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.

  • Dorin
    2019-02-18 02:59

    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.

  • Duong Tan
    2019-03-15 02:55

    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.

  • Matt Diephouse
    2019-02-25 07:58

    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 aren't problems anymore outside of niche applications.Additionally, Brooks' main thesis about man-months is most often misquoted and misunderstood. He writes that people and months aren't interchangeable and that adding people to late projects will only make them later—because people initially have a negative contribution. The details of that aphorism are incredibly important, but always forgotten.It would be nice to see a new, updated book on this topic that includes actual data and measures concepts from this century. But I did find Brooks' articulation of a few other concepts helpful. Among them:Simplicity and straightforwardness proceed from conceptual integrity.By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases 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.

  • James Oden
    2019-02-23 03:12

    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 time and time again has been found wanting. Additionally, his prose smacked of someone who was all to enamored with his own thoughts. The Mythical Man Month ultimately fell flat in my estimation, though I can understand why at one point it was a highly lauded book. It would be better I think if someone pulled out the true bits of wisdom from Mythical Man Month and wrote a new book that took into account the state of the art, and had a tone that was less self-laudatory.

  • Nikos Karagiannakis
    2019-03-05 09:04

    Ο εκδοτικός οίκος ζήτησε από τον συγγραφέα να μην αλλάξει τίποτα από το αρχικό κείμενο και, επιπλέον, να προσθέσει 4 νέα κεφάλαια.Στα τελευταία κεφάλαια, ο συγγραφέας κάνει έναν απολογισμό των συμπερασμάτων της αρχικής έκδοσης (1974) σε σχέση με το τι ισχύει την εποχή της επετειακής αυτής έκδοσης (1995).Η τεχνολογία των αρχικών κεφαλαίων φαντάζει από παλιά και άκρως ενδιαφέρουσα (όπως θα έλεγε κάποιος, σαν εμένα, που ο πρώτος του υπολογιστής ήταν ένα Sinclair ZX81) έως προϊστορική (όπως θα έλεγε κάποιος που ο πρώτος του υπολογιστής ήταν ένα MacBook Air). Παρ' όλ' αυτά όμως, η διαχρονικότητα των εννοιών που περιγράφονται στο βιβλίο είναι εντυπωσιακή.

  • Megha
    2019-03-04 07:10

    04/23/11Dr. 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.

  • Mouly
    2019-03-16 10:07

    * 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 delay. * Avoid cramming features in the second system (reminded me of Vista)* Written specification is very important. It should describe everything that the user can see about the product.* Algorithm can be predicted from the data tables.* Small number of documents become the pivots of product management (Objectives, Specifications, Schedule, Budget)* Quantify change by using version numbers * More bugs are found as the number of users increases* Things are always their best at the beginning* Repairs (software) increase entropy * "Sustained concentration reduces thinking time"* Milestone should be concrete, specific measurable events. Pay strict attention to even the slightest delays, Projects get delayed one day at a time.* Hard part of building software is: specification, design, & testing* Creative activity has three steps: 1. Formulation of conceptual construct 2. Implementation in real media 3. Interativity with users in real uses* "Conceptual integrity of the prodcut as percerived by user is the most important factor in ease of use"* Use keyboard shortcuts to design for power users and novices* "People with more time take more time"* Recommeded books: Peoplware: Productie Project teams, and Small is Beautiful

  • Philipp
    2019-03-18 06:55

    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 persons. Have version control (since the book is old, it's more of a central repository of printed (!!) books that detail all changes, the outline, the design etc.). There is no silver bullet - software is inherently complex and there will never be a single technology which makes it fast/easy/cheap/error-free.A large portion of the knowledge contained is more useful large companies or large projects, where you have 100 to a 1000 programmers working at the same time, so for me as a lonely bioinformatician toiling on my own code not everything is applicable. But if I look through failed projects at, for example, Kickstarter, I realize that they often just repeat mistakes people already solved in the 70s. This review has a good summary of the main points.I'm giving it 4 stars since some of the examples, discussions and problems are clearly outdated by now.

  • Joan
    2019-03-11 02:55

    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, and the quirks of computers. Unfortunately, Mythical Man-Month has a gender problem. Every pronoun was "he," except for the occasional references to secretaries and nurses, who of course are women. In addition, the book makes oblique references (a few) to women's place in the home. It's gross, unnecessary, and incredibly frustrating. Time for a 2016 edition.

  • Senthil Kumaran
    2019-03-20 11:08

    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 kind of expertise and experience which Fred Brooks possessed. I hope we all read this as entertaining account and try to get some insights in the process of software development.

  • Jim
    2019-03-16 08:02

    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 professionals have never read this book, never heard of Brook's Law or Second System Syndrome (and suffer for it).

  • Tiago
    2019-03-20 08:10

    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 the last chapters. However, almost everything applies, because the book focus are the general lessons that never get outdated.

  • John Mehrman
    2019-03-06 08:02

    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.

  • Shyam
    2019-03-17 05:02

    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.

  • ABC
    2019-03-20 04:23

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

  • Amy Jones
    2019-03-21 02:55

    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.

  • Ondrej
    2019-02-23 08:22

    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 getting 20 years worth of feedback, Brooks also changed some of his opinions on matters described in original book, which was nice to read from a historical perspective. 4/5.

  • Alison Rowland
    2019-02-19 06:58

    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.

  • Emil A Eklund
    2019-02-19 07:17

    Read it a long time ago and it really should be required reading for all eng-managers and pms.

  • Rizky Januar
    2019-03-19 03:19

    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 basic thinking framework regarding the nature of software.One of the lessons is about managing people and time in software projects. The author states that one cannot substitute man and month directly. In other non-software construction projects, if you want to build faster, you can add more people. But that doesn't apply in software projects. If you add more new people in the middle of a project, there are learning curves and also communication overhead that must be taken care of. Consequently, the man-month doesn't grow linearly.Another lesson is a chapter titled "No Silver Bullet" stating that there is no single technique can improve the software development process by an order of magnitude in a decade. This proposition is discussed a lot in the book.Mostly, the chapters are short. Only few are long. However, the author uses many metaphors that make me, a non-native speaker, difficult to digest the content. Many terminologies are also from the old time, which I am not quite familiar. The kind of the software projects presented is a system product i.e. an operating system. At the end of the book, the author gives his views after 20 years since the book published. I definitely recommend this book.

  • Benjamin Hare
    2019-03-13 10:10

    No other book about programming has had such an impact on my life. The timelessness of this work is remarkable, considering it was first published in 1975 and the topic of software development evolves at such a blistering pace. Frederick P. Brooks, Jr. is a brilliant, erudite writer capable of conveying both the beauty and tribulations of programming on a large scale. Having never worked on a large programming project, I am not qualified to argue his conclusions, but I can say they are valid for the tiny, minute, level of programming I am familiar with. For prose alone, the book is worth reading, even for those outside of the computer industry. There is also a historic value in the work as a window into the inner workings of the industry to which I owe my livelihood.I've read this book all the way through probably five times since first discovering it in 2004 in a Barnes & Nobles in Virgina. Since that time I've gone through three copies; two given to friends, and a third that fell apart after years of scribbling it with commentary and diagrams. I'm now on my fourth copy and have already lent it out twice. It's that kind of book.A deep chord of virtue resonates between the lines of each essay. Never before have I read a work about the noble art of programming that makes me feel such a swell of pride in the craft itself.

  • Dom
    2019-03-06 08:23

    Thought provoking and impressive in that it seems to contain many timeless insights. Bit less action oriented and lucid than Peopleware, but worth reading anyway. Act uno animo, with hierarchy. Authority to come from momentum of accomplishment. Builders ain't monkeys. Centre gains authority by delegating power. Conceptual integrity gives ease use. Communicate, for the love of god, Communicate. Constraints conduct innovation. Critical path and less important termites. Design and grow, don't build. Dual-ladder-equal-prestige organisation. Featuritis. Matrix management of functional specialists. Probabilistic and deterministic. Pure thought-stuff, infinitely malleable. Scaffold or STDs of extra work. Sequential constraints. Sine cera. Skepticism vs pessimism. Software ain't a building. Some aristocracy needs no apology. Surgeon and co-pilot. System program building, metastable entropy a decreasing process. Termites not tornadoes cause delay. The idea, the implementation and the interaction are in the mind of the maker. Total-system, user-oriented attitude. Unleashing constraints. Vehicles of opportunity and opportunity space.

  • Jay
    2019-03-16 10:19

    Nonfiction very related to my actual job thing. I thought these essays, written many decades ago, are still so accurate. I'm planning to bring some of these ideas into my life as I plan how to make better software. And to meet schedules better.