The Mythical Man-Month

I find that programmers seem better at coordinating work and communicating about work compared to other fields that I have experience with. The work is organized in a much more humane way than the email inbox driven hyper-active hive-mind model of other office workers so vividly described in Cal Newport’s in “A World Without Email”. In fact, programmers seem to already be living in that future utopia of an emailless world. How did it get to be this way? I think this book may have played a major role.

Despite being only a few years removed from computer programs consisting of stacks of cards, high level languages being a new thing compared to assembly language, and changesets being distributed via microfilm, this book, originally published in 1975, outlines a way of developing software that resonates today:

In “The Surgical Team” Brooks outlines the roles required in a software development shop: The surgeon/copilot (product development), the administrator (project management), the toolsmith (dev-ops), and the tester (QA).

In “Why Did the Tower of Babel Fail”, Brooks advocates for a “Project Workbook” with features that today are available in tools such as Jira and Github.

The idea of developing a MVP and iterating on it is the topic of “Plan to Throw One Away”.

“The Other Face” advocates for writing self-documenting code with meaningful names, formatting, and comments. These ideas are greatly expanded on in Clean Code by Robert C. Martin.

That said I would not recommend this book for someone just wanting to get up to speed on these topics. For one thing, I found the outdated language distracting; as the title suggests, every programmer in this book is a “man.” Much of the book is spent discussing obsolete software and hardware systems. But as a fascinating time capsule into the history of computing and the development of the practice of programming it is worth a read and still offers relevant lessons 48 years later.

The Mythical Man-Month is a collection of classic papers on software engineering, with some additional commentary (particularly in the 1995 edition) and connective tissue to turn them into an approachable narrative.  It dates from a time when software engineering consisted of moderately large teams of programmers working on software packages written mostly in assembly or machine language for mainframe and minicomputers.  The majority of the essays in the book are from the author’s experience on the OS/360 operating system project for IBMs enormous System/360 mainframe computer.  At the time, OS/360 was one of the (or possibly the) largest software development efforts ever attempted.

While the above description makes it sound like the Mythical Man-Month is as dated as the woodcut of a mammoth struggling in the La Brea tar pits found on its cover, the author did an amazing job of extracting insights about software development that not only stand the test of time, but also apply to much smaller projects — including projects of the scale that students are likely to encounter in their classes.  It is sprinkled throughout with observations and aphorisms that are immediately useful.  The most famous of these is probably Brooks’s Law, which states that “Adding manpower to a late software project makes it later.”  For my own part, I find the observation “Plan to throw one away; you will, anyhow” to be my favorite advice in the book.

In addition, Brooks’s description of the The Joys of the Craft of software development in Chapter 1 is one of the most beautiful summaries of the field that I have ever read.  I will leave you with this quote:

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

The Mythical Mythical Man-Month.

This book is definitely dated, and I bet that's one of the sources of my frustration for it.

Another is its romantic outlook. It starts by telling you, the programmer, why you love programming, because apparently the author knows. And what he says is how programming is pure thought put into action, just like God's word created the World. I bet I'm misquoting, but it doesn't matter much.

Later on, the author talks about phenomena that he has noticed in the process of making computer systems, and I keep feeling that it's all just romantic assumption that the author probably correctly observed in many cases and then, as it happens, liked and instinctively felt the need to generalize them and saw them in everything. Perhaps they exist and I'm talking crap, but it feels a lot like faith.

I do see why the book was so valuable and popular, though. It introduces a way to think about software production that specifically takes into account the innate characteristics of it, and it's differences to other engineering fields. That is brilliant and visionary, and I liked it.

I didn't read through the whole book, and I never will. I think whatever good principles exist there have been filtered into the programming discipline, and I don't have much to gain. I also think that even some fallacious or romantic principles have also seeped into our culture, and I don't want to read about those.

Most of the stuff in Fred Brooks' Mythical Man-Month is stuff I've read in one place or another over the years. However, I'd never read all of it in one place and it had been a while. When I heard the audio of his presentation at OOPSLA 2007, I grabbed a copy and read it through.

The details and examples are definitely showing their age, but the underlying principles, including the source of the title still ring true 35 years after he wrote them the first time. There are some myths of software development that just seem to have imbibed the zombie powder. They just won't die.

I've lost count of the number of project managers who seem to think that they're going to be the first to add people to a late project and speed it up. Re-reading these essays invigorates my desire to challenge that assumption more emphatically when it comes up.