This is one of the iconic book of its time. Apparently it had a great influence. The book was republished in 1995 and author decided not to change much. Big mistake. The book has two type of content: very relevant and ridiculously outdated.
Unfortunately I run out of patience of sorting those two and I didn’t finish the book. I would not recommend this book.
The key message that you should not estimate software work in man hours because they don’t scale linearly. The communication and management overheads grow with the team size. Adding people to already late project will only delay it as there are onboarding costs.
Below are my highlights.
Chapter 1: The Tar Pit
I estimate that a programming product costs at least three times as much as a debugged program with the same function.
Chapter 2: The Mythical Man-Month
our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.
Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them
The added burden of communication is made up of two parts, training and intercommunication.
Adding manpower to a late software project makes it later.
Chapter 3: The Surgical Team
These studies revealed large individual differences between high and low performers, often by an order of magnitude.
— Sackman. Erikson. And Grant
the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!
The data showed no correlation whatsoever between experience and performance.
Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
Chapter 4: Aristocracy, Democracy, and System Design
Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design.
For a given level of function, however, that system is best in which one can specify things with the most simplicity aiid straightforwardness.
Schedule pressures, however, dictate that system building needs many hands. Two techniques are available for resolving this dilemma. The first is a careful division of labor between architecture and implementation. The second is the new way of structuring programming implementation teams discussed in the previous chapter.
Where architecture tells what happens, implementation tells how it is made to happen.
the conceptual integrity of a system determines its ease of use.
the total creative effort involves three distinct phases: architecture, implementation, and realization. It turns out that these can in fact be begun in parallel and proceed simultaneously.
Chapter 5: The Second-System Effect
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.
…