Goodreads helps you keep track of books you want to read.
Start by marking “Мифический человеко-месяц или как создаются программные системы” as Want to Read:
Мифический человеко-месяц или как создаются программные системы
Enlarge cover
Rate this book
Clear rating
Open Preview

Мифический человеко-месяц или как создаются программные системы

4.05  ·  Rating details ·  9,876 ratings  ·  657 reviews
Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного прое ...more
Hardcover, Профессионально, 304 pages
Published 2009 by Символ (first published 1975)
More Details... edit details

Friend Reviews

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

Reader Q&A

Popular Answered Questions
Stavros Sachtouris You don't need to be experienced in anything to understand this book. To enjoy it, though, it might be necessary to be familiar with engineering or…moreYou don't need to be experienced in anything to understand this book. To enjoy it, though, it might be necessary to be familiar with engineering or project management. It doesn't have to be software or electrical engineering, any kind would do. IT people will enjoy it even more for its historical and anecdotal value.(less)
This book is not yet featured on Listopia. Add this book to your favorite list »

Community Reviews

Showing 1-30
4.05  · 
Rating details
 ·  9,876 ratings  ·  657 reviews


More filters
 | 
Sort order
Manny
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
Jan-Maat
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
David Bjelland
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 ...more
Daria
Dec 05, 2015 rated it it was ok  ·  review of another edition
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
Pratul Kalia
Apr 03, 2016 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.
Brian Yahn
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
...more
Igor Tsinman
May 01, 2011 rated it it was amazing  ·  review of another edition
Shelves: programming, the-best
The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks это уже классика. Все, кто хоть как-то связан с компютерами и/или проектами просто обязаны прочесть эту книгу. Заказчикам тоже не помешает узнать как все выглядит на самом деле.

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

В Израильслих стартапх эта книга хорошо известна, а выражение "Silver Bullet"
...more
Graham
Nov 01, 2009 rated it really liked it  ·  review of another edition
Shelves: computer-books
I read this book originally in college and then re-read it after a couple years of coding professionally. While there are certainly some dated sections, such as the idea of having the analog of a surgical team to code, many of the suggestions have held against the test of time.

The two most popular are "no silver bullets" and "adding developers to a late project makes it later." The former is that no new technology/technique will make an order of magnitude difference in productivity over 10 year
...more
Dorin
Apr 10, 2017 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.
Matt Diephouse
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
Bill
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
...more
Canan
May 09, 2019 is currently reading it  ·  review of another edition
en bilinen kısmı unutmuşum:) “The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.”
Nente
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.
Duong Tan
Mar 06, 2014 rated it it was amazing  ·  review of another edition
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
Philipp
Aug 07, 2012 rated it really liked it  ·  review of another edition
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
James Oden
Oct 03, 2015 rated it it was ok  ·  review of another edition
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
Nikos Karagiannakis
Ο εκδοτικός οίκος ζήτησε από τον συγγραφέα να μην αλλάξει τίποτα από το αρχικό κείμενο και, επιπλέον, να προσθέσει 4 νέα κεφάλαια.

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

Η τεχνολογία των αρχικών κεφαλαίων φαντάζει από παλιά και άκρως ενδιαφέρουσα (όπως θα έλεγε κάποιος, σαν εμένα, που ο πρώτος του υπολογιστής ήταν ένα Sinclair ZX81) έως προϊστορική (όπως θα έλεγε
...more
Megha
May 12, 2011 rated it liked it  ·  review of another edition
Shelves: non-fiction
04/23/11

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

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

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

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

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

* If a project is delayed - rescheduling or reducing scope is recommended. Adding manpower will result in further de
...more
Joan
Jan 31, 2016 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
Senthil Kumaran
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
Jim
May 14, 2016 rated it it was amazing  ·  review of another edition
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
Tiago
Jan 02, 2009 rated it it was amazing  ·  review of another edition
I have read it as part of my PhD, since it's part of the classical books of software engineering. Yet the book tackles very important issues not only about management but how people interact during software development. I've recognised myself in many situations described by the author (even that I'm not part of a software development team).
One might wonder, as I did, how many of the concepts explained by the author apply to current technology of the 21st century, but the author tackles that in t
...more
John Mehrman
Sep 12, 2017 rated it it was amazing  ·  review of another edition
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
Nov 07, 2011 rated it really liked it  ·  review of another edition
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.
ABC
May 28, 2017 rated it it was amazing  ·  review of another edition
I just leave my rating at here and dont say anyfuckinthing.
Thomas Dietert
May 02, 2019 rated it it was amazing  ·  review of another edition
In the context of this history of software engineering and management best practices for effectively building software systems and managing all sizes of projects and teams, this book is invaluable. I recommend every software engineer who is interested in building software systems at a meta-level (technical/social systems that help you build software systems), or wants to gain insight into these processes. Remarkably, only the specific methods and tools mentioned have changed since this book was ...more
Amy Jones
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
Feb 10, 2018 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
Alison Rowland
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.
« previous 1 3 4 5 6 7 8 9 next »

Readers also enjoyed

  • Rapid Development: Taming Wild Software Schedules
  • Peopleware: Productive Projects and Teams
  • The Practice of Programming (Addison-Wesley Professional Computing Series)
  • Joel on Software
  • Facts and Fallacies of Software Engineering
  • Patterns of Enterprise Application Architecture
  • Programming Pearls
  • Death March
  • Beautiful Code: Leading Programmers Explain How They Think
  • Design Patterns: Elements of Reusable Object-Oriented Software
  • Extreme Programming Explained: Embrace Change (The XP Series)
  • The Psychology of Computer Programming
  • The Pragmatic Programmer: From Journeyman to Master
  • Seven Languages in Seven Weeks
  • Mastering Regular Expressions
  • Refactoring to Patterns
  • The Art of UNIX Programming
  • Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)
See similar books…

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »
“Adding manpower to a late software project, makes it later.” 10 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.” 9 likes
More quotes…