Frederick P. Brooks (1931–2022)

Fred Brooks was in charge of a big software development project for IBM in the late sixties. As usual with big projects, the product came in late and over budget, it didn't quite perform as well as had been hoped, and by the time it was on the market there were new technologies coming up that would soon make it obsolete. Rather unusually for a manger, Brooks decided to devote some serious thought to why that had happened, and the result was this little book, in which he lays out some basic show more principles of project management that have application far beyond the (now largely forgotten) world of big mainframe computing.

The two big quotable ideas in the book are things you've probably seen on a Powerpoint slide if you've ever done project management training.

Firstly, the one that gives the book its title, the idea that real life jobs don't work like those famous maths problems where one worker digs a ditch in ten days and ten workers can therefore dig the same ditch in one day. In real life, the bigger a team gets the more complex the interactions between team members become, and the more time is consumed in internal communication, meetings, paperwork, administration, etc. This seems a very obvious point, but it's one I've often seen overlooked in real life. Senior managers love the idea of big, complicated teams, and it always ends in long delays and mountains of paper...
(It being 1975, Brooks talks about "men" and "man-months" throughout, except in his example of a non-divisible job: "If it takes nine months for one woman to produce a baby...")

Secondly, as a kind of corollary to this, he proposes Brooks's Law: “Adding manpower to a late software project makes it later.” This is a kind of paradox, of course, but the phenomenon it describes is one that probably happens in every workplace. You're overloaded with work, so your boss recruits someone to help you, and the backlog initially gets worse as you have to divert time into training and supervising the newcomer. In a fairly generic job that soon gets compensated as the new person becomes productive, but in a complex project it can rapidly turn a small delay into a catastrophe.

Beyond these headline ideas there is a lot of sound advice about what works and doesn't work in terms of team-structures, meetings, intermediate goals, and effective documentation strategies, all of which is readily portable outside software development (and a lot of which also seems to have survived into today's formal project-management systems). Specific to computing projects, he talks about the importance of focussing design effort on specifying what the product should do, and making sure that that fits within a unified vision, preferably defined by a single architect. The nuts and bolts of how the specification is implemented will take far less time to design than the specification itself.

The 1995 edition comes with a couple of follow-up essays looking at responses to the book, with some thoughts about what he would revise in the light of the unexpected ways computing has evolved. The personal computer revolution, with the consequent shift from expensive custom software to commercial "shrink-wrapped" solutions, has taken him by surprise, as has the rise of object-oriented programming, but neither of these things seems to invalidate the basic principles he set out. show less

This book was written in the sixties, yet, I find its recommendations and requirements for software development are just as helpful, humorous and educational in the 21st century. I still don't understand how they got any work done back then with manually teletypes, printed requirements documents being updated everyday and the like, but they still had the exact same problems we do now.

The two things I took away most, "the more people you add to a late project, the later the project is." show more Along with the title of the mythical man month, is the idea "nine women can't make a baby in a month." The other point, was that whatever your estimate is for development time, you need to consider at least twice as much for validation. This is counter intuitive, you develop it once, you test it once, and that test takes less time than writing code did, but there is so much more. The covers testing for each release, it covers finding regressions later, and any other issue that may be written against that piece of code that wasn't exposed when it was first authored. These good testers make bug fixing much easier. show less

Brooks is a supremely experienced developer, a solid and subtle thinker, and a very fine writer, both in terms of organization and presentation of ideas and the quality of his sentences. This book is both a must-read and a pleasure to read.
The issues that Brooks addresses may have changed in their specifics - I see very little talk about Ada in my other readings on computer science - but not in their essentials. I read several chapters of this book this morning in a coffee shop, then pulled show more out a stack of printouts to try to understand someone else's code, and much of what I had just read was alive in what I was doing. The importance of clarity and craftsmanship in the design of code: the code I was reading was Java, but written like C, constantly taking advantage of accidents of language to achieve reasonable results in baffling ways. The difficulty of development and maintenance: it took me about ten hours of hard work to begin to understand the organization of this code, before I could begin to address the problems of refactoring, adding features, and documentation which constitute the project I'm assigned to. The "plan one to throw away" concept: the initial code will be refactored, but only in the sense that it will be completely rewritten in place. However, the original writer's ideas provide a lot of the initial mistakes that we would have made ourselves, so his time was not by any means wasted, nor was the time I spent understanding his code. The list goes on - and Brooks understood it all, thirty-five years ago, before object-oriented programming was even a concept. show less

Although much of the approach Brooks advocates has been common practice in the software industry in the 30 years since the book's publication, The Mythical Man-Month remains as relevant today as when it was written. It references obsolete platforms like System/360 and Multics, and is set in a world where punch cards and PL/I were state-of-the-art, but human nature hasn't changed. The few parts that are truly irrelevant remain charming, like this comment: "The Apostle Peter said of new show more Gentile converts and the Jewish law, 'Why lay a load on their backs which neither our ancestors nor we ourselves were able to carry?' I would say the same about new programmers and the obsolete practice of flow charting."

This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs!

[2006-07-24] show less