The Mythical Man-Month

When I was a graduate student in the mid-1950s, I could read all the journals and conference proceedings; I could stay current in all the discipline. Today my intellectual life has seen me regretfully kissing subdiscipline interests good-bye one by one, as my portfolio has continuously overflowed beyond mastery. Too many interests, too many exciting opportunities for learning, research, and thought. What a marvelous predicament! Not only is the end not in sight, the pace is not slackening. We have many future joys.

Peopleware. A major contribution during recent years has been DeMarco and Lister's 1987 book, Peopleware: Productive Projects and Teams. Its underlying thesis is that "The major problems of our work are not so much technological as sociological in nature."

The trick in the design of such a tree is to put near its root those design decisions that are less likely to change.

The second fallacy of the waterfall model is that it assumes one builds a whole system at once, combining the pieces for an end-to-end system test after all of the implementation design, most of the coding, and much of the component testing has been done.

The waterfall model puts system test, and therefore by implication user testing, at the end of the construction process. Thus one can find impossible awkwardnesses for users, or unacceptable performance, or dangerous susceptibility to user error or malice, only after investing in full construction. To be sure, the Alpha test scrutiny of the specifications aims to find such flaws early, but there is no substitute for hands-on users.

the waterfall model assumes the mistakes will all be in the realization, and thus that their repair can be smoothly interspersed with component and system testing.

After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect. Defining distinct roles in such small teams may be a little extreme, but I have observed it to work well and to contribute to design success even for small teams.

A second explanation often advanced is that The Mythical Man-Month is only incidentally about software but primarily about how people in teams make things.

Human history is a drama in which the stories stay the same, the scripts of those stories change slowly with evolving cultures, and the stage settings change all the time.

He argues that costly and late projects invest most of the extra work and time in finding and repairing errors in specification, in design, in implementation. He offers data that show a strong correlation between lack of systematic quality controls and schedule disasters.