Customer Reviews

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

5 star:		(116)
4 star:		(25)
3 star:		(12)
2 star:		(6)
1 star:		(4)

 

 

If you have managed some software projects or have worked on some non-trivial software systems, undoubtedly you have faced many difficulties and challenges that you thought were unique to your circumstance. But after reading this book, you will realize that many of the things you experienced, and thought were unique problems, are NOT unique to you but are common systemic problems of developing non-trivial software systems. These problems appear repeatedly and even predictably, in project after project, in company after company, regardless of year, whether it's 1967 or 2007.

You will realize that long before maybe you were even born, other people working at places like IBM had already experienced those problems and quandries. And found working solutions to them which are as valid today as they were 30 years ago.

The suggestions in this book will help you think better and better manage yourself, and be more productive and less wasteful with your time and energy. In short, you will do more with less.

Some of Brooks insights and generalizations are:

The Mythical Man-Month:
Assigning more programmers to a project running behind schedule, may make it even more late.

The Second-System Effect:
The second system an engineer designs is the most bloated system she will EVER design.

Conceptual Integrity:
To retain conceptual integrity and thereby user-friendliness, a system must have a single architect (or a small system architecture team), completely separate from the implementation team.

The Manual:
The chief architect should produce detailed written specifications for the system in the form of the manual, which leaves no ambiguities about any part of the system and completely specifies the external spcifications of the system i.e. what the user sees.

Pilot Plant:
When designing a new kind of system, a team should factor in the fact that they will have to throw away the first system that is built since this first system will teach them how to build the system. The system will then be completely redesigned using the newly acquired insights during building of the first system. This second system will be smarter and should be the one delivered to the customer.

Formal Documents:
Every project manager must create a roadmap in the form of formal documents which specifies milestones precisely and things like who is going to do what and when and at what cost.

Communication:
In order to avoid disaster, all the teams working on a project, such as the architecture and implementation teams, should stay in contact with each other in as many ways as possible and not guess or assume anything about the other. Ask whenever there's a doubt. NEVER assume anything.

Code Freeze and System Versioning:
No customer ever fully knows what she wants from the system she wants you to build. As the system begins to come to life, and the customer interacts with it, he understands more and more what he really wants from the system and consequently asks for changes. These changes should of course be accomodated but only upto a certain date, after which the code is frozen. All requests for more changes will have to wait until the NEXT version of the system. If you keep making changes to the system endlessly, it may NEVER get finished.

Specialized Tools:
Every team should have a designated tool maker who makes tools for the entire team, instead of all individuals developing and using their private tools that no one else understands.

No silver bullet:
There is no single strategy, technique or trick that will exponentially raise the productivity of programmers.

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 manage." This short book (at just over 300 pages) does a masterful job answering that question.

It is here we first hear of Brooks's Law: "Adding manpower to a late software project makes it later." Brooks doesn't just drop that on the reader without explanation. Instead, he walks through the reasoning, discusses how communication in a group changes as the group changes or grows, and how additions to the group need time to climb the learning curve.

Those new to the industry or who are reading the book for the first time might be put off by the examples and technology discussed. Indeed, even in the newly released edition, the original text from 1975 is still present, essentially untouched. So, talk of OS/360 and 7090s, which permeates the text, is perhaps laughable to those not looking deeper. When talking about trade-offs, for example, Brooks offers "... OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is day 366). That might have been left to the operator." This is 26 bytes he's talking about!

Brooks provides a light, almost conversational tone to the prose. This isn't to say the observations and analysis were not very well researched. Comparing productivity number with those of Software Productivity Research (SPR), you'll find Brooks came up with the same measurements for productivity as Jones--only 20 years earlier!

Other wisdom is also buried in this work. Brooks declares "The question, therefore, is not whether to build a pilot system and throw it away. You will do that. The question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers." The state of products I buy today tells me not enough people have taken Brooks's observations to heart!

The latest version of the text includes his work "No Silver Bullet." Brooks, who had brought us so much before, had one last "parting shot."

As I started this review I will also end it: this book is a classic. Read it.

In giving testimony before Congress a few years ago on IT issues, I said the following:

"Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don't fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded."

I have been involved in software engineering for over 25 years, have written many articles and even a few books on the subject. Yet every time I think I've discovered some new insight, chances are I can find it tucked away somewhere in The Mythical Man-Month. And the tarpits and other dangers he lays out plague the IT industry today. I wonder when we will grasp and apply the fundamental insights that Brooks, Jerry Weinberg, and others laid out nearly three decades ago. ..bruce..

This book is a classic, but recently revised and corrected. The amazing thing is how relevant the book still is to software product development. If you are involved in software, this book is a must-read.

The most valuable part of the book, I believe, is the "plan to throw out" prototype chapter. While the goal is always to make a bigger, better, fast whatever, it is almost an axiom that you WILL build something that has to be discarded and reworked. This absolutely happens every time, I can tell you from first-hand experience. Therefore it is vital to plan to throw out so you can migrate your users to whatever will follow. If you dream that the first product is THE ONE, you risk abandoning them on a product that will inevitably evolve. Planning the throw-away also helps meet the schedule goals by setting reasonable milestones that can be met.

In my role as a product manager for a top-selling software product in its class, I found that the Mythical Man-Month was absolutely vital. However, some additional reading is recommended; Walker Royce's Software Project Management was published in 1998 and adds the dimension of software project evolution. This goes into more detail why you can't write all the specifications upfront, and even if you do, they are certain to change by the time the product is released.

I find myself going back to this book regularly as management tries to double the size of a team in order to cut development time in half, or make supervisors out of great technical people. Normally when you read a technology book as old as this one, its distracting to see how much things have changed; in this case, its sobering to see how little things have changed. Brooks' project examples are artifacts of another era, but teams are still failing to deliver quality software on time for all the same reasons they were then. There's room for disagreement with some things in the Mythical Man-Month (most of which are addressed in the new chapters at the end), but it convinced me that making project deadlines doesn't have to be a roll of the dice, and gave me the insight to start looking at software development as a process instead of as an accident.

Most of what you'll read in this book will not come as a surprise, you've heard it before; well, this is the source. These are observation like: Programmers who really think they found the last bug mess up your planning (since they didn't), the last 10% of a software project may take more resources to complete than all used so far and adding resources to a project will only make it finish even later.
This very book has left a tremendous impression on the industry ever since it was first printed (1971?) although most mistakes are still made. Virtually all examples are outdated like "--the date should be changed manually for a leap year, this saves some 50 bytes in main memory--" but anyone can substitute relevant examples.
The author's main argument is that no "silver bullet" will be invented that can decrease the time to perform a complex software project significantly. In this 1995 edition the author admits (in a new chapter) that some of his conclusions are incorrect but he stays with that argument: the silver bullet was not invented and will not soon (if ever) be invented.

Almost everyone who works on projects with the IT industry is familiar with Brooks' Law (cited in the review title). But all too few people have read this seminal book on project management and software engineering. Containing resources such as an explanation of Brooks' Law, an incredibly useful breakdown of what kind of documentation should accompany a product, and the new chapters which examine what's changed since the book was first released. The whole world would be saved a great deal of chaos if beginning project managers would start with this fine book.

I was initially sceptical that a book on software engineering written twenty-five years ago could still be relevant today. It is.

This short, concise book contains a handful of highly insightful essays, each focusing on one main topic, usually a problem area in software engineering, and possible ways to solve it. Brooks doesn't waste pages of space in excess verbosity. He just says what he thinks, and why he thinks it. It's a very underrated writing technique.

The new chapters in the anniversary edition serve to acknowledge changes that have occurred since the original edition, and while there have been some, on the whole, most of the original text still stands. If you are in the field, or want to get into it, read this book. Simple.

This was one of the most valuable books in its day (1975). It revealed huge mistakes in one of the largest programming efforts ever, and suggested mostly-reasonable improvements.

But software engineering has advanced a lot since then, even if the software industry hasn't. For example, Brooks' sole team-level improvement is the suggestion to use Harlan Mills' chief programmer teams, while many such improvements have been found since then. And Brooks entirely ignores the main defect of the chief programmer team---the difficulty of finding chief programmers!

(As an aside, a chief programmer team works fine now with a chief programmer, a college grad, and modern tools. Code ought to be written so a college grad can maintain it, and this approach helps ensure that. The college grad can also flesh out test cases and support in other ways. But there's still the problem of finding the chief programmer...)

Brooks approach is generally, "We did that wrong. We should have done it this way, for these logical reasons." But there are often several solutions to a problem, all having logical reasons. Empirical data is needed to choose between them. Brooks rarely mentions alternate solutions, and almost never offers emperical data.

A far more valuable book is Steve McConnell's "Rapid Development". This well-researched and organized book quotes data to confirm problems, discusses solutions with associated emperical data, and recommends solutions.

I cannot think up any other book that would come close to being as effective as this one when it comes to solid, down to earth advice on the management of software projects.

Direct and to the point in its presentation, and built on actual experience gathered during years of work, the book lays down its insight in an extremely effective and efficient manner, making for both an interesting and an effective read. Quantity wise, the book addresses many issues surrounding the world of software project management, issues that usually take several books for others to explore.

Although the book is old, with references to old technologies that serve best as comic relief nowadays, it is quite amazing to see how true and how valid the insights gathered by the author are today. My own experience and discussions I have had with colleagues from reputable Fortune 100 companies helped me realize how relevant the book still is: Decades after it was written, project managers everywhere still approach software projects with attitudes that would never be accepted elsewhere and are still attempting to cut corners they should not cut. They all end up paying the price, just as the book predicts.

The bottom line is that this book is a true classic: Extremely effective, concise, readable, entertaining - and one that withstands the test of time.