This book is one of the most famous essay in Computer Science. Written by Frederick P. Brooks Jr in 1975, the book describes one of the most famous software law: “Adding manpower to a late software project makes it later”.
Frederick P. Brooks is a computer architect who worked at IBM and managed the System/360 family of computers and the OS/360 software support package. Armed with extensive knowledge in software product management, he wrote the essay “The Mythical Man-Month”. This book puts development practice under the spotlight and earned its author the National Medal of Technology in 1985 and the Turing Award in 1999.
Early on in the book, Brooks lists the following 5 joys of programming:
- Sheer joy of making things
- Pleasure of making things that are useful to other people
- Fascination of fashioning complex puzzle-like objects
- Joy of always learning
- Delight of working in a tractable medium
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
Of course, not everything is joy and a programmer may also face the following woes:
- One must perform perfectly
- Dependence on other people’s objectives and programs
- Finding nitty little bugs is just work
- Testing drags on and on
- Product may appear obsolete upon completion
This then is programming, both a tar pit which many efforts have floundered and a creative activity with joys and woes all its own.
As explained in the first chapter, a program needs 1) a programming system and 2) a programming product to be complete. This implies interface system integration, generalization of the program, testing, documentation and of course, maintenance. For a good program coming out of a “garage style startup” to become a well-rounded programming systems product, it needs about nine times more resources and time. Indeed, any decision made while developing a program may change its specification:
- Project descriptions and requirements
- Space and resources allocation
- Assignment of staff and work
The book goes on talking about calendar, setting up requirements and budget. It elaborates on the optimism when working on a project:
So the first false assumption that underlies the scheduling of system programming is that all will go well, i.e., that each task will take only as long as it “ought” to take.
The Mythical Man-Month
What is a man-month? A man-month is a hypothetical unit that describes the amount of work a person can accomplish within a month.
… in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence, the 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.
When a work can be partitioned into tasks like “picking apples”, then time versus workers follow an inverse quadratic function. However, when the tasks cannot be partitioned like in system programming, the time versus workers follow a constant relation. With the trade-off of communicating, adding a new person to a project may end up lowering the process.
When the team is small such as in a medical surgery team (around ten people), the tasks can be partitioned fairly well into communication patterns where each person follows the order of its immediate superior. However, when the same concept is scaled up to a multinational company with thousands of employees, the transfer of concept depends on the conceptual integrity of each piece involved. As a project goes on, changes are bound to happen. Hence, organization is key.
In my opinion, what makes this essay so amazing is the great writing style. Brooks writes eloquently and uses metaphors to explain his theory. The Babel tower was an especially clever example. As a developer himself, he understands the “joys and woes inherent in [system programming]”. I love that he understands the pleasures of programming, of solving problems and even making the world better. Hence, when he goes on about the struggles to complete a project, I know he is pouring his soul and experiences into words. The ideas are definitely worth considering. A young developer may learn from it the importance of good communication and the struggles of large scale projects; a senior management executive may learn from it how to better allocate resources and man power.