I read this as an EE teaching a class on microcontrollers which has me going outside of my hardware comfort zone. The text was interesting, if I didn't mind cringing at all the male pronouns and references to god. (Which was a LOT of cringing.) ( )

I read this just after publication, and was absorbed in the story. I was lucky enough to get to work on the first IBM 360 computers (which this story is about) and it was so very relevant to my work. And it was a fine tome on management. ( )

Good essence with many interesting lessons that still hold true. However, I fell most of it is only interesting from an historical perspective as so much has changed in the field. ( )

This book was written in the sixties, yet, I find its recommendations and requirements for software development are just as helpful, humorous and educational in the 21st century. I still don't understand how they got any work done back then with manually teletypes, printed requirements documents being updated everyday and the like, but they still had the exact same problems we do now.

The two things I took away most, "the more people you add to a late project, the later the project is." Along with the title of the mythical man month, is the idea "nine women can't make a baby in a month." The other point, was that whatever your estimate is for development time, you need to consider at least twice as much for validation. This is counter intuitive, you develop it once, you test it once, and that test takes less time than writing code did, but there is so much more. The covers testing for each release, it covers finding regressions later, and any other issue that may be written against that piece of code that wasn't exposed when it was first authored. These good testers make bug fixing much easier. ( )

This has held up amazingly well for a book about software engineering written in 1975. Fred Brook's insight into human behaviour is still spot-on even though the technical details can be amusing when you realize that their mainframe had less storage capacity than an RFID tag… ( )

Fred Brooks was in charge of a big software development project for IBM in the late sixties. As usual with big projects, the product came in late and over budget, it didn't quite perform as well as had been hoped, and by the time it was on the market there were new technologies coming up that would soon make it obsolete. Rather unusually for a manger, Brooks decided to devote some serious thought to why that had happened, and the result was this little book, in which he lays out some basic principles of project management that have application far beyond the (now largely forgotten) world of big mainframe computing.

The two big quotable ideas in the book are things you've probably seen on a Powerpoint slide if you've ever done project management training.

Firstly, the one that gives the book its title, the idea that real life jobs don't work like those famous maths problems where one worker digs a ditch in ten days and ten workers can therefore dig the same ditch in one day. In real life, the bigger a team gets the more complex the interactions between team members become, and the more time is consumed in internal communication, meetings, paperwork, administration, etc. This seems a very obvious point, but it's one I've often seen overlooked in real life. Senior managers love the idea of big, complicated teams, and it always ends in long delays and mountains of paper...
(It being 1975, Brooks talks about "men" and "man-months" throughout, except in his example of a non-divisible job: "If it takes nine months for one woman to produce a baby...")

Secondly, as a kind of corollary to this, he proposes Brooks's Law: “Adding manpower to a late software project makes it later.” This is a kind of paradox, of course, but the phenomenon it describes is one that probably happens in every workplace. You're overloaded with work, so your boss recruits someone to help you, and the backlog initially gets worse as you have to divert time into training and supervising the newcomer. In a fairly generic job that soon gets compensated as the new person becomes productive, but in a complex project it can rapidly turn a small delay into a catastrophe.

Beyond these headline ideas there is a lot of sound advice about what works and doesn't work in terms of team-structures, meetings, intermediate goals, and effective documentation strategies, all of which is readily portable outside software development (and a lot of which also seems to have survived into today's formal project-management systems). Specific to computing projects, he talks about the importance of focussing design effort on specifying what the product should do, and making sure that that fits within a unified vision, preferably defined by a single architect. The nuts and bolts of how the specification is implemented will take far less time to design than the specification itself.

The 1995 edition comes with a couple of follow-up essays looking at responses to the book, with some thoughts about what he would revise in the light of the unexpected ways computing has evolved. The personal computer revolution, with the consequent shift from expensive custom software to commercial "shrink-wrapped" solutions, has taken him by surprise, as has the rise of object-oriented programming, but neither of these things seems to invalidate the basic principles he set out. ( )

Excellent Project Management Theory

Fred Brooks was a software engineer at IBM for some decades and later chair of the UNC CS department. His experience and study makes this recounting invaluable. I felt like I highlighted a sentence on every other page. You must get the second edition and if you read nothing else in it (though it is a short book), you must read the 18th and 19th chapters. The 18th chapter is a summary of all prior chapters while the 19th chapter reflects on the book 20 years later in 1995 -- what changed and what hadn't. ( )

Good start, loses some insight later on due to age. Overall I liked it. ( )

Very good. Another one of those pretty amazing books that has relevance far beyond it's specific scope and time. Some of the chapters were also interesting just as a window into the big issues, challenges and concerns that have since been completely overcome.

The part that really most interested me was about the productivity of the great being ~ an order of magnitude better than even the good, and on top of that the fact that adding people has far from a linear impact. It's all about the right people.

Might have been a useful read 20 years ago, but any pm of more then a couple of years experience and worth a fraction of his salary should be already aware of the major points in this book. ( )

What is relevant about a book, in its second edition, that was originally written a generation or two ago about managing computer projects? The author Brooks led the management of the project for IBM decades ago.

The answer to this question is simple and is evident in the title. Scaling software projects from smaller-to-larger does not scale linearly. In case you don't know what this means, scaling non-linearly means that a project twice as big does not require twice as many "man-months." It more likely requires four times as many "man-months" because of the need for communication among programmers.

Brooks shows the aged wisdom of the idea that computer programming is indeed part communication and not fully mathematical problem solving. Brooks then tries to figure out how to manage projects that are larger and that require more communication. Many of the references are aged and not for those who don't appreciate the history of computation. Nonetheless, for those who like to dabble in history, Brooks' take - always bright - makes us see that the problem of successfully managing software projects is not a new one. Indeed, there are timeless values which undergird technical success.

This anniversary edition includes a retrospective account that evaluates many of the propositions originally put forth decades ago. (Brooks was mostly right, we see.) However, I wish Brooks would also lend some ink - in the light of the additional experience of a couple of decades - to the questions of what makes a software project successful in the first place. Merely being right should fade while understanding timeless values should come to the fore. ( )

While a classic, the book is obviously dated. Some of the advice is dated and some of it no longer relevant (concerns about tape drives, documentation on microfiche, etc.), but some of it, including the classic advice about adding people slowing down projects, is still relevant. And I have a certain fondness for even the outdated parts, although some of it goes over my head by referencing things I've never heard of (including OS/360, his prime example). ( )

An interesting read of a classic - mostly not relevant to today I would suggest, but some lessons which remain valid. ( )

A decent & quick read, but many of the essays in the book are obsolete and not applicable to most programmers. However, the core essays that made this book famous are definitely worth a look. ( )

Must read to understand what is software engineering and project management ( )

Often, a book such as this, which is ground-breaking at the time of publication, loses much on its way through time. This work is still timely, and the lessons (sadly) still need to be learned. My favorite of anything Dr Brooks said:

"Nine women can't make a baby in one month."

The chapter entitled "Why Did the Tower of Babel Fail?" has the most instructive and useful discussion I've seen on how to manage a large programming (or other) project. It's brief, to the point, and leaves nothing out.

This is not just a historical book; it's still useful, and I recommend it. ( )

I especially enjoy Brooks' discussion about the effort that goes into the 'productization' (i.e. packaging etc.; pretty much all non-coding work) of software. ( )

Eh. Very interesting and potentially useful concepts - at least, if I were planning or managing a major software project. But as soon as he gets down to details, it turns into a mildly interesting discussion of computer history. When he spends an entire chapter (well, nearly) on the advantages of time-sharing terminals as opposed to batch debugging...yeah. Not really helpful in terms of what we've got now. The final chapter - the update, as of 1995 - is more interesting but still outdated - he spends a lot of time talking about this wonderful new thing, object-oriented programming. Which is useful, in exactly the ways he discusses - but it's also the way I learned programming in college, so he doesn't have much he can teach me. The most interesting part, actually, was when he pointed out that about then, the 1990s, there had been a major switch in programming - it went from basically all custom-built programs, designed from the ground up for one particular company and usage, to what he calls "shrink-wrapped" packages like Excel and FoxPro, where the program is built to be general-use with thousands or millions of users each working with it slightly differently. It does make a major change in considering the programming process - the specification of the program get both looser (because they don't have to match one client's specific needs) and tighter (because they have to be useful in a whole lot of different situations). The cost variable does too - if you're spending thousands of man-hours on one program for one client, it's a couple hundred thousand dollars minimum to make it worthwhile. If you spend those same thousands of man-hours on one program that will be bought over and over and over by different clients, each one can be quite cheap. I wonder if MS Office pricing is a remnant of the older cost structure? It's not thousands of dollars, but it's pretty pricy for what you get. Anyway - the point is, by the time I was paying attention to commercial programming, shrink-wrapped was the norm and custom was that weird way government and a few retro companies insisted on getting software. I really hadn't realized that it had ever been another way. So - I learned some things, the history was interesting, but that's a read-once. The concepts might have been useful, but the illustrations used are so out of date that I can't apply them to anything I'll actually do. So, as far as I'm concerned, no longer a particularly useful book. Glad I read it, don't need to (ever) reread. ( )

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. ( )

Even after 15 years from the publication of the anniversary edition, this software engineering and project management classic has remained surprisingly relevant. It presents many ideas that have since become very famous, like that adding people to a late project may only serve to make it later. Sure, there are some parts that haven't aged as well, but even those have historical value. The book certainly clarified my thinking on large software projects, and provided lots of valuable fodder for thought. Brooks's thoughts on conceptual integrity, the intrinsic complexity of problems and abstraction are insights that every software engineer needs to flourish. If you don't get them from this book, be sure to get them elsewhere. ( )

I was intrigued to find my computer-programming-major son reading the 20th Anniversary edition my favorite book from my career days (before he ws born!). He verified that nothing much has improved in computer programming since I quit teaching in the Eighties. Brooks's additional four chapters confirm most of his original work, with a few exceptions. ( )

Brooks is a supremely experienced developer, a solid and subtle thinker, and a very fine writer, both in terms of organization and presentation of ideas and the quality of his sentences. This book is both a must-read and a pleasure to read.
The issues that Brooks addresses may have changed in their specifics - I see very little talk about Ada in my other readings on computer science - but not in their essentials. I read several chapters of this book this morning in a coffee shop, then pulled out a stack of printouts to try to understand someone else's code, and much of what I had just read was alive in what I was doing. The importance of clarity and craftsmanship in the design of code: the code I was reading was Java, but written like C, constantly taking advantage of accidents of language to achieve reasonable results in baffling ways. The difficulty of development and maintenance: it took me about ten hours of hard work to begin to understand the organization of this code, before I could begin to address the problems of refactoring, adding features, and documentation which constitute the project I'm assigned to. The "plan one to throw away" concept: the initial code will be refactored, but only in the sense that it will be completely rewritten in place. However, the original writer's ideas provide a lot of the initial mistakes that we would have made ourselves, so his time was not by any means wasted, nor was the time I spent understanding his code. The list goes on - and Brooks understood it all, thirty-five years ago, before object-oriented programming was even a concept. ( )

The classic project management reference for information system development.

A must read for anyone who calls himself a 'Project Manager' or wants to become one. ( )

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.

That aside, Brooks does a a fantastic job of discussing how software "is done", the contributions of each role on the team and how things get very complex very quickly as the size of the project scales up. His insights remain poignant and his credibility increases as many of his predictions from 1975 ring true today.

And while Brooks does talk about ease of use and how important it is that the application meets the needs of the people who use it, he never mentions the role of the Usability Practitioner. Is this an oversight or an active decision or was there simply no such thing as a Usability Practitioner in 1975? I would have expected him to note the role in one of his many follow-up chapters.

Speaking of which, my only critique is with the structure of the book. Brooks has returned over the years to add follow-up chapters such that its hard to distinguish what is the end of the original book and what was added later.

Wisdom is a hard thing to come by. You gain it slowly by experiencing life yourself or maybe a little faster by learning from others experience. As someone working in the field of software development its incredibly helpful to be able to differentiate temporal issues from an issue that is simply innate to the work we do. I feel I'm all the wiser for the read and I wish Mythical Man Month were required reading for my colleagues ( )