The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

This was one of the first software engineering books I ever purchased (Not the 20th Anniversary Edition). It is still one of my favorite software books and I re-read it every year or so. Some of Brooks' solutions to common problems are showing their age but the issues he raises are timeless. Some of my favorite chapters are:

The Tar Pit - every project I have ever worked on has been a Tar Pit at some point, even the best ones. Brooks shows why this happens.

The Mythical Man-Month - the source of the quote "The bearing a child takes nine months, no matter how many women are assigned." and the observation that adding more programmers to a project can actually delay its completion. The sources of scheduling woes were identified by Brooks long ago but we still live with them.

The Second System Effect - it amazes me how many times I've seen this happen and still don't realize it until it's almost too late. I need to read this chapter more often.

Why Did the Tower of Babel Fail? It's all about communication.

The wisdom in this book has become so ingrained in our industry that people quote it without even realizing it.. Brooks is a great writer and makes this an easy read. You could read this book in a couple of days but work a life-time to appreciate its value.

The Mythical Man-Month (M M-M) [Frederick P. Brooks] is often referred to as the most influential Software Engineering books ever. Despite being originally published in 1975 the content remains timeless, equally valuable today.

The central theses of these essays revolve around conceptual integrity - maintaining the product focus in large systems (IBM's OS/360). Brooks touches on many other topics such as the need for a software process, how to manage a team, and the importance of distinguishing between the architecture, design, and development processes. Brooks approaches most subjects from an abstract (managerial) perspective requiring personal interpretation (reading between the lines).

"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)

Throughout the book Brooks continually emphasizes the need for remaining analytical (objective), and his famed "No Silver Bullet" essay can be found in Chapter 16.

"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)

The Mythical Man-Month is enjoyable, a wealth of information, and easy to read. Some readers may be discouraged, as this book requires personal interpretation, but in doing so the M M-M facilitates inspiration, introspection and debate. Anyone associated with the software industry (introduction level programmer through to management) can appreciate what Brooks has to say.

If you're looking for a comprehensive checklist or an immediately implemental solution then read what other authors like Steve McConnell (Code Complete: A Practical Handbook of Software Construction) and Robert L. Glass (Facts and Fallacies of Software Engineering) have to say.

"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18)

This classic on software engineering made its mark as a study of how to manage large complex projects. Most of the book applies to management in general rather than to software engineering in particular.

Here are two examples of the more general insights the author, former IBM manager Frederick P. Brooks, gives readers: an instance of a straightforward insight immediately applicable, and another one we obtain by carefully (!) reading the text.

Brooks looks at different types of projects; large projects that can be split into many simple independent tasks will be completed faster if we add more staff to carry them out. However, engineering projects are seldom so simple. Developing software for a new machine requires the machine, which is itself being developed, as well as documentation, which is being prepared! All these tasks relate to each other and require all participants to communicate with each other. The number of communication lines within a team grows exponentially with respect to the number of team members. At some point, adding more men and women actually delays project completion, shattering the myth of the man-month.

However we must be careful as we read the Mythical Man Month. This book was written in the seventies about the author's experiences in the sixties, so to understand Brooks correctly, we've got to read him carefully. For instance, Brooks praises PERT charts, saying outright that "there is no substitute" for them. I can't believe this is a blanket endorsement for mindlessly turning out slides and charts by using Microsoft Project! Brooks didn't have MS Project or PowerPoint in the sixties: PERT charts were carefully drawn, often by hand, they were expensive, and they were prepared after thinking things through. We find the true insight a little further down page 156: "The preparation of a PERT chart is the most valuable part of its use".

Some of the book is of course more relevant to software engineering. For instance, Brooks's correct 1986 prediction that off-the-shelf, shrink-wrapped software would become the standard way to implement solutions. Just look at Microsoft Office or at SAP's R/3 to see the truth of this. (I'd even say that because powerful software is now so cheap, we've created a glut of output.)

Read properly, The Mythical Man Month remains as insightful today as in the seventies and eighties. Brooks's style is friendly but professional and business like. Budding project managers will find many useful insights.

Vincent Poirier, Tokyo

After reading Eric Raymond's book "The Art of UNIX Programming", I realized there were important concepts to learn about the software development PROCESS itself. I had heard of this book, but didn't know much else about it beyond its title. I was stunned when I first saw its original publication date, and almost didn't bother reading it. Luckily for me, I started it, and the first chapter captured my mind so entirely that I didn't put it down until I'd finished the entire book (that same Saturday). This book gave me an insight into how the people of the last 50 years developed the industry of software development, and the insights of Fred Brooks back in 1975 still had an impact on me and the processes I saw in practice at my job and in the various "new" development methodologies I'd heard about in the industry today. I highly recommend this to anyone who's been in the software development environment for at least three years... I think that having less experience would make it difficult for you to step back and look at your own processes from a higher plane... this book would sound more to you like a project manager's work diary rather than the true gem that it is.

I highly recommend reading this book if your a fresh graduate, Software Developer, Project Manager, play an architectural role or are in any way connected software Project irrespective of its size and complexity.

This book was especially important for me, I read it just before I began as program manager with a startup.

The book offers insight into the key roles behind every Project, timelines, product integrity, size, programmer efficiency, productivity, communication and other variables that have a significant impact on Software projects. The author does not preach, instead he offers clear-cut arguments based on his experiences as the architect of OS/360 with IBM. Objectively evaluate them for yourself. This book definitely offers a tremendous learning experience.