There are a few books that are recurring on the “top 10 books every software engineer must read”-lists on the Internet, and one of them is The Mythical Man-Month. I’ve been trying to read more nonfiction lately, and especially books that deal with software and its development process. As a result I’ve had The Mythical Man-Month on my nightstand for the last few weeks.

The book was originally published in 1975 and received an update for its 20th anniversary, which included a few extra chapters. The author, Fred Brooks, received a Turing Award for his efforts in the field of computing in 1999.

Okay, enough with the backstory. As can be expected from a forty year old book, anachronisms are plentiful. This was a time were the available amount of memory was measured in bytes without any prefix, documentation was updated, printed and physically distributed and, perhaps most importantly, computer-time was a scarce resource.

The problem with the book is its age, by which I don’t mean these kinds of anachronisms. Our field has thankfully moved forward somewhat in the last 40 years, even though Bret Victor might not agree. Instead, the main problem is that during this period in time (60s and 70s), the reigning development process was what we refer to as waterfall.

I should be fair and point out that this very problem is highlighted by Brooks in the last chapter, which was added in 1995 and contains his own reflections on what had changed in the last 20 years. The fact still remains though that large portions of the book deal with typical waterfall model problems. The most prominent such problem is perhaps how to better create system specifications that are complete and correct, a task which for most real systems is unfeasible.

There are however good points that are valid even today. For example, when defining milestones for a project, they “must be concrete specific, measurable events defined with knife-edge sharpness” so that team members have no way of fooling themselves that something is “basically” finished.

The author is also obviously aware of the problems with changing requirements, stating that “both the actual need and the user’s perception of that need will change as programs are built, tested and used”.

The book is interesting, but assuming you are working in a fairly modern organization (by which I mean you don’t strictly follow the waterfall model) I don’t believe it will push you or your manager to enlightenment. The best part of the book was actually the new chapter discussing the differences in the field between 1975 and 1995, so if you want to read it I would recommend you do so with the goal of better understanding the earlier days of software engineering, rather than learning how to structure the perfect organization.

Finally, I do not wish to imply that dealing with changing requirements is a solved problem. Agile methodologies have given us better tools, but there is a reason that we are not all using the same process. It seems Fred Brooks was correct when writing that “structuring an organization for change is much harder than designing a system for change”.