A worthwhile read, though all the practical advice is rather outdated. If understood in abstract terms, though, much of it is still applicable.
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."
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.
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.
|Addison-Wesley Publishing Company, Inc.||Publisher|
|Frederick P. Brooks, Jr.||Author|