Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering fact...
read full description
reviews
Jul 27, 2011
Igor
rated it: 
The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks это уже классика. Все, кто хоть как-то связан с компютерами и/или проектами просто обязаны прочесть эту книгу. Заказчикам тоже не помешает узнать как все выглядит на самом деле.
The Mythical Man-Month это кладезь, хорошо изложеных замечаний, идей, рекомендаций и еще масса прочего полезного материала. 100 процентов идей Брукса актуальны сегодня!!!
В Израильслих стартапх эта книга хорошо известна, а вы More...
The Mythical Man-Month это кладезь, хорошо изложеных замечаний, идей, рекомендаций и еще масса прочего полезного материала. 100 процентов идей Брукса актуальны сегодня!!!
В Израильслих стартапх эта книга хорошо известна, а вы More...
4 comments
like
(7 people liked it)
Sep 06, 2011
Graham
rated it: 
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 diff More...
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 diff More...
0 comments
like
(3 people liked it)
Nov 23, 2011
Joecolelife
rated it:
There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.
In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to mana More...
In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to mana More...
Aug 23, 2011
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. More...
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. More...
9 comments
like
(1 person liked it)
Oct 16, 2011
Sondra
rated it: 
I decided to revisit a few classic management books recently, and I'd always been curious about this one, since it's specific to my field. Originally published in 1975, much has changed in the business of developing software. Most of Brooks examples are taken from OS development teams, and a few chapters emphasize the old tradeoff of memory and speed or functionality. He even suggests that documentation be kept on microfiche. However there is much that is still relevant, such as the usual bu
More...
0 comments
like
(2 people liked it)
Aug 03, 2011
Dan
rated it:
Reading this book has been on my "to-do" list for about 20 years so I'm pleased I finally got round to it and it didn't disappoint. Of course, it's an old book (with some additional newer material added) and some of what it covers no longer applies or has been superseded. However, there is still massive relevance in much of what Brooks said back in 1975 and it's amazing how much of it is still largely ignored.
Tomorrow morning I will go back into work as usual on a programme with proj More...
Tomorrow morning I will go back into work as usual on a programme with proj More...
Jul 19, 2010
getAbstract
rated it:
Philosophical essays on software, projects and purpose
This book is a classic for a reason. Every essay by Frederick P. Brooks Jr. addresses software engineering and proves invaluable for those interested in the history and processes of that field. getAbstract also recommends Brooks’ book to anyone who plans or organizes major projects. The collection remains timely due to the clarity of his thought and the educated loveliness of his prose. When Brooks is writing about programming, he More...
This book is a classic for a reason. Every essay by Frederick P. Brooks Jr. addresses software engineering and proves invaluable for those interested in the history and processes of that field. getAbstract also recommends Brooks’ book to anyone who plans or organizes major projects. The collection remains timely due to the clarity of his thought and the educated loveliness of his prose. When Brooks is writing about programming, he More...
Apr 18, 2010
Mouly
rated it:
* 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. Addi More...
0 comments
like
(1 person liked it)
Aug 06, 2009
Arden
rated it:
I had heard about this book and the concept of the "Mythical Man Month" before I found it in my college library this summer. I was really excited to read it after finishing the first chapter, but the more I read it, the more dated it seemed. There are several references to high level languages such as Ada and the promising emergence of object oriented programming that were startling reminders that this book was originally published in 1975. I did appreciate reading it for the historica
More...
Jul 11, 2009
Nicholas
rated it: 
This review has been hidden because it contains spoilers.
To view it, click here
Apr 16, 2008
Jeanne
rated it:
I found the essays informative, from a historical and theoretical perspective, but not a lot of help in how to improve management of projects. There are many far better books than this one for actual "how to" tips and tricks.
3 comments
like
(1 person liked it)
Jan 11, 2010
Chibimagic
rated it:
This book is one of the classics of software engineering, and with good reason. Though half the book is only applicable if you're building an operating system in the 1960s, the other half remains very much true today. You can see the foundations of agile and a formal QA process. It's remarkable how after 35 years, we still haven't learned some of the lessons that were recognized in the 70s: a single visionary for conceptual integrity, separate parallel managerial and technical career ladders, es
More...
Jan 06, 2012
Ondřej
rated it:
See how software was developed 50 years ago. It was interesting to observe, how many things have changed since the microcomputer revolution and thanks to the rate, with which the development in hardware and software had progressed. And how the time of the people programming the computers became incomparably more valuable than the computer time.
Though, this is more a book abound managing development than the actual programming, and it is even more interesting to see that so many managem More...
Though, this is more a book abound managing development than the actual programming, and it is even more interesting to see that so many managem More...
Nov 22, 2011
Sergey
rated it:
The book definitely is out of date.
Everything is completely changed - approaches, principles of teamwork.
I'm wondering why so many people gave good ratings to this book?
30 years ago software development was very expensive because of poor technologies, crap hardware, absence of helper tools - you had to think ten times before actually do something.
Nowadays, time to market is the key principle. You have to push something to public first, then think about a More...
Everything is completely changed - approaches, principles of teamwork.
I'm wondering why so many people gave good ratings to this book?
30 years ago software development was very expensive because of poor technologies, crap hardware, absence of helper tools - you had to think ten times before actually do something.
Nowadays, time to market is the key principle. You have to push something to public first, then think about a More...
Jan 03, 2010
Jeb
rated it:
I know that this is the book on the management and leadership of software engineering, but I have to say that I was a little let down.
First of all, it was incredibly dated. Can't blame the author for that, certainly, but useful suggestions about how a team of programmers ought to share a terminal session mean nothing when I've got four powerful computers on my desk at work.
It wasn't completely unredeeming, and I found some of the ideas intriguing, like the authors sugges More...
First of all, it was incredibly dated. Can't blame the author for that, certainly, but useful suggestions about how a team of programmers ought to share a terminal session mean nothing when I've got four powerful computers on my desk at work.
It wasn't completely unredeeming, and I found some of the ideas intriguing, like the authors sugges More...
Jan 02, 2009
Tiago
rated it:
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 More...
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 More...
0 comments
like
(1 person liked it)
Feb 09, 2012
Gregg
rated it:
If I could only recommend one book on project management, The Mythical Man-Month would be that book.
I had an opportunity to hear Professor Brooks teach on the subject while he was writing the book and bought a copy as soon as it was released. That was shortly before I started my degree in CS...
I have found its advice invaluable in project management, not only for software projects, but just about any project I've ever been part of. And it presages many of the agile and More...
I had an opportunity to hear Professor Brooks teach on the subject while he was writing the book and bought a copy as soon as it was released. That was shortly before I started my degree in CS...
I have found its advice invaluable in project management, not only for software projects, but just about any project I've ever been part of. And it presages many of the agile and More...
Nov 16, 2010
Nick
rated it:
I give it three stars, but it probably deserves four -- several of the maxims herein have percolated into the wider community, and were known to me well before I first came across this. Brooks, by the way, has written more than this rather soft title -- his report on the IBM 360, for instance, is the first paper in Readings in Computer Architecture.
More...
Apr 23, 2011
The author received in 1999 the ACM's A. M. Turing Award, which, according to the back cover is "the most prestigious award in the computing field." He is cited for "landmark contributions to computer architecture, operating systems, and software engineering."
Chapter 1: The Tar Pit. In this chapter, I learned the distinction between a "program," a "programming product," a "programming system," and a "programming systems product More...
Chapter 1: The Tar Pit. In this chapter, I learned the distinction between a "program," a "programming product," a "programming system," and a "programming systems product More...
May 20, 2010
Nikolay
rated it:
Ако се занимавате с правене на софтуер, задължително я прочетете. Наистина.
Аз я прочетох малко късно. Доста от нещата вътре или бях чувал или бях осъзнал по други пътища. Въпреки това беше поощрително и поучително да ги прочета накуп, описани с истински думи и то смилаемо.
Ако ще я четете, не се занимвайте с друго издание освен с най-новото (поне 20 години след първоначалното). В есетета примерите са ужасяващо остарели и дори някои принципни неща са се променили. В новото More...
Аз я прочетох малко късно. Доста от нещата вътре или бях чувал или бях осъзнал по други пътища. Въпреки това беше поощрително и поучително да ги прочета накуп, описани с истински думи и то смилаемо.
Ако ще я четете, не се занимвайте с друго издание освен с най-новото (поне 20 години след първоначалното). В есетета примерите са ужасяващо остарели и дори някои принципни неща са се променили. В новото More...
Jan 27, 2011
Brad
rated it:
MMM is the rare technology book that has sustaining value over decades. I enjoy it on many levels. There is nostalgia, and I continually gasp at how far we have come in computing in so short a period of time. There is history, and we see the beginnings of techniques and methods we now take for granted, like iterative development and the software architect role. There is science and engineering applied to the task of analyzing the software development process. There are pearls of wisdom abou
More...
Aug 06, 2009
Arden
rated it:
I had heard about this book and the concept of the "Mythical Man Month" before I found it in my college library this summer. I was really excited to read it after finishing the first chapter, but the more I read it, the more dated it seemed. There are several references to high level languages such as Ada and the promising emergence of object oriented programming that were startling reminders that this book was originally published in 1975. I did appreciate reading it for the historica
More...
Oct 27, 2008
Mike
rated it:
Durable classic about software development. Articulated in a medium quite tractable to the designs of its creatives, software still exhibits an essential in-tractability that bedevils all but the most trivial of projects. Castles made of sand cannot scale to tide-resistant permanence, they quickly resolve into the native equilibrium of strand and sea. More resolute constructions require more resolute methods.
The book is full of little gems, such as the line "The bearing of a chil More...
The book is full of little gems, such as the line "The bearing of a chil More...
Aug 19, 2008
William
rated it:
THE classic book on the human elements of software engineering, updated two decades later in this edition by the award-winning author with the addition of four new chapters. Immediately popular when first published, the 20th anniversary edition was received by that generation of software engineers just as enthusiastically as was the first. Whole sentences from this book regularly constitute the majority of top-ten or even top-twenty lists of favorite quotes and pearls of wisdom from the field. I
More...
Oct 11, 2008
Andrea
rated it:
A book about technology, first written in 1975 and yet still - astoundingly - relevant.
Imagine reading along, mentally applying the lessons to your own experience when the author notes that great efficiencies would be gained if only everyone had a desktop computer... my god! This book is ancient (in terms of technology)!
And that's what is both instructive and disturbing - the I.T. field is still struggling with the same issues they struggled with a quarter century ago. More...
Imagine reading along, mentally applying the lessons to your own experience when the author notes that great efficiencies would be gained if only everyone had a desktop computer... my god! This book is ancient (in terms of technology)!
And that's what is both instructive and disturbing - the I.T. field is still struggling with the same issues they struggled with a quarter century ago. More...
Dec 27, 2009
Andy
rated it:
Basically a collection of adages, an old computer engineering veteran sharing his battle-tested lessons as to what works and what doesn't in the software industry. Like many adages, it doesn't really tell you what you don't already know (see the author's amusing anecdote in the 20th anniversary edition's afterword)... but you may find it helpful to be reminded of them from time to time.
In my opinion, the book can be distilled into just a few bullet points: Software development is no More...
In my opinion, the book can be distilled into just a few bullet points: Software development is no More...
Jul 02, 2011
Tom
rated it:
This book remains a timeless classic of sound advice for software engineering. I really respect how specific references to technology 40 years old remains in this anniverary edition. It helps to highlight how the foudational truths have stood the the test of time. File it next to Programming Pearls and be a better software engineer for having read both, which together have more sagely advice of practical use than, say, a thicker Scott McConnell tome ("Code Complete") and I like his boo
Jan 18, 2009
steve
rated it:
This review has been hidden because it contains spoilers.
To view it, click here
May 28, 2011
Gary
rated it:
This is an old school book but many of the concepts will extend into the future. It talks about how groups should be formed in order to create large software systems and the division of thought, labor and power which allows many people to simultaneously change code. There are very strict guidelines needed to create an efficient software team.
The book is very hard to read but the content is interesting and so I would recommend it to any more advanced software engineers.
-Gary
The book is very hard to read but the content is interesting and so I would recommend it to any more advanced software engineers.
-Gary
Dec 03, 2009
Arnauld
rated it:
A "must read" book for any software professional. Full of good common sense advice on software projects management. Though over 30 years old, most conclusions are still applicable today. It's amazing that today deciders still make the same mistakes about sofware projects, while the causes of failures are known since so long. Offer this book to your manager if you ever heard the "I need this for yesterday, get 10 more progammers and have them finish this *now*!" sentence.
