Frederick Brooks’ The Mythical Man-Month is an odd sort of book. It’s a book about software projects written in 1975, but it’s not entirely worthless today; for a book about software development to be at all relevant 30 years later is a pretty impressive achievement.

But it’s a bit of a patchy one, I’m afraid. The book is a collection of essays, most from the original 1975 edition, but with some updates from the 20th anniversary edition in 1995. Some of the essays — the general, high-level ones — have survived well. Some of the others... well, not so much. Unless you’re still writing COBOL, I suppose. I’m not, so skipped over the dated bits.

The book’s most famous essay is obviously its titular one, the main point of which is that you can’t substitute people for time, culminating in the famous Brooks’ Law: Adding more people to a late project makes it later. Unfortunately for me, this essay was relatively weak. The fundamental insight is one that most people have absorbed, and there’s really not much more there — very little elaboration or supporting evidence. I actually find my faith in Brooks’ dictum weakened by reading this lightly-evidenced essay.

The article that I thought was worth the price of admission was “No Silver Bullet,” which attempts — rather successfully — to make the case that there’s not going to be any magical programming tool that results in a quick order of magnitude improvement in programming productivity. His argument is, essentially, that such improvements used to be possible because 90%+ of programming effort was spent on the accidents of programming (memory allocation, low-level I/O, etc.) rather than on the essence of it (defining the problem in useful detail, defining the solution in useful detail); but that these days, a minority of time is spent on the accidents, and the majority is the essence — and tools are great at removing the amount of crap you need to wade through to get to the core of what you’re trying to do, but they can’t do a thing for the ineradicable complexity of the problem domain and its required solution.

At any rate, this is a book worth browsing; but despite its reputation as a classic of the field, I don’t think it’s a must-read for anyone these days. The state of the art has moved on, and Brooks’ seminal work is the sort of thing that should be cited, not read.


{{}} said {{timeAgo(comment.datetime)}}