A worthwhile read, though all the practical advice is rather outdated. If understood in abstract terms, though, much of it is still applicable.

1: The Tar Pit

2: The Mythical Man-Month

From this chapter we get the famous "Brooks's Law":

Adding manpower to a late software project makes it later.

Due to training time and the additional communication overhead, adding new people to a project will cause a substantial productivity loss initially.

Additionally, Brooks notes that we estimate badly:

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

This is the planning fallacy.

Programmers, Brooks says, are optimists:

All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy god-mothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run,'' or "I just found the last bug."

3: The Surgical Team

4: Aristocracy, Democracy, and System Design

5: The Second-System Effect

6: Passing the Word

7: Why Did the Tower of Babel Fail?

Due to lack of communication, Brooks says. As with many of Brooks's practical suggestions, the exact details of his solution are outdated–we won't be using either stacks of paper or microfiche–but the principle is solid: communicate changes in detail, and include a summary of changes that will allow people to keep up to date without reading every changed line. In short: Keep a Changelog.

Brooks's suggestions for team composition are similarly specific to his time and his particular niche, but the basic idea–arrange responsibilities so that people only need to worry about their special spheres of expertise, where possible–is still good.

8: Calling the Shot

Larger programs are more complex, so productivity–or lines of code per man-year, as a proxy–drops precipitously as project size increases. Additionally, people tend to overestimate the rate of code production and debugging.

It is again outdated, but Brooks correctly suggests that using a high-level language will multiply productivity substantially. Today, we should think about this as similar to Brooks's suggestion to produce useful tools early in the process, and to have people dedicated to this task. If the system (taken to include the language used, tools available, etc.) supports the work of the engineers, then productivity increases.

9: Ten Pounds in a Five-Pound Sack

10: The Documentary Hypothesis

11: Plan to Throw One Away

12: Sharp Tools

13: The Whole and the Parts

14: Hatching a Catastrophe

15: The Other Face