BiblioTech
CTech’s Book Review: Myth of Product Version 1.0
Sequoia Capital general partner Gili Raanan on Frederick Brooks' "The Mythical Man-Month"
Title: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition
Author: Frederick Brooks
Where: at home and during vacation
The Mythical Man-Month (left). Sequoia Capital general partner Gili Raanan. Photo: Ariel Bashor
One-liner: Don't build a software product before you have read the book
Summary: in 1992, as a young officer serving in the Israeli Intelligence corps, I was tasked with a very simple project: "take 8200 off the IBM mainframe". Endless lines of code, databases, scripts, applications— all need to be refactored for the new age of PCs and Unix servers. Overnight, I was in charge of the largest software project the Israeli military has ever performed, with no experience in running such a project. Taken aback by the scale of the mission, I was referred to "the Mythical Man-Month," and equipped with the wisdom quickly acquired from it, I approached my first national scale software project with much less fear than I had originally.
Bottom line: there are very few texts that have survived the test of the ages and are still helpful and impactful today. "The Mythical Man-Month" occupies the top of a very short list. The book, by Frederick Brooks, is an essay on software engineering and project management based on his experiences at IBM while managing the development of OS/360.
What I’ve learned:
Shortening birth by involving more women: when a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.
Tasks involving communication take more time: men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.
Involving new people slows down work initially: adding manpower to a late software project makes it later.
Delivering too soon: software projects are like an omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices: wait or eat it raw. The cook has another choice; he can turn up the heat.The result is often an omelette nothing can save: burned in one part, raw in another.
Critique: the text precedes the time of agile development, continuous development, and many other common practices in software development. Regardless, the book is not about standards or practices, it is about interaction, biases, and the people behind complex software projects.
Who should read this book: anyone in the software business, especially startup founders whose company's product is actually their first real scaled software project. It will help them realize how to size development teams, how to sequence their steps, and how to expect and resolve constraints.
