This is a book that every software engineer has heard of and many of them have read it. And finally I also read it. What can I sayтАж It is a wise book despite the fact that it is almost as old as I am.
The book makes a number of observations on how large projects are being developed. It is funny that large project management was already an issue in 1950s. Many people think (including myself) that during those years programmers were only writing simple programs such as computing some mathematical function or solving an equation. But much more complex software systems were being developed even in 1950s. Therefore, at the time when the book was written a large amount of experience has already been accumulated.
The first claim that the book makes is that developing a reusable software is much more difficult than writing a prototype implementation. Issues such as interoperability testing and documentation can consume as much time as writing code itself.
In the next chapter the author presents what later became the so-called BrooksтАЩ law: adding programmers to a late project can only further delay it. The reason is that in many large projects most time is spent in communication or mis-communication.
Then the author presents an ideal software engineering team: the Surgical team in which each member knows his exact responsibilities and does his job well. Brooks points out that managers should take responsibility for the architecture and convey it clearly to software developers. This ensures that the project has consistent APIs and is well-structured overall.
Despite that many software engineers know these rules in theory, when it comes to practice everybody can recall numerous violations in their owns experience.
So if large teams spend a lot of time on communication, would not it make sense to always use small teams of 2-3 people? It would, as long as the amount of work is not big. But a small team has a fundamental limitation on the amount of man-hours they can tackle. For example, it takes millions of man-hours to implement an operating system, and a small team cannot do it within foreseeable future.
Btw., another interesting observation Brooks makes is that the productivity of a programmer is always 200-300 statements per day, no matter which language is used. This is a fundamental constraint that project managers have to accept. This means that with the current statement-based languages one cannot expect a 10-fold increase of productivity. On the other hand, as programming languages adopt more and more expressive constructs, the productivity of programmers increases anyway.
The book tries to shed the light on the future of programming and mentions various visual efforts aimed at increasing the productivity as well as easing the learning. In fact, projects such as Scratch aim at providing a visual environment in which beginners can build their programs easily without learning programming. So this is still an area of on-going work.
Compared to the current state-of-the art project management technology, this book appears as ancient classic textbook which many people have read but few have listened to. To me it seems that many people do not trust a guy who wrote something 30 years ago in such a dynamic field as software development. This is why people are more willing to adopt Agile methodology whose characteristics are quite opposite to the concept of Surgical team, Vertical system design, etc. However, it is not clear yet whether Agile is an always-win methodology or there are situations in which BrooksтАЩ approach is better. I can only say that project management is getting more and more complicated, just as the complexity of the software itself.