The Mythical Man-Month: Essays on Software Engineering / Frederick P. Brooks, Jr.

Tal Cohen's Bookshelf: A Collection of Personal Opinions about Books

Friday, 24 April 1998

If a certain job can be done by ten people in one month, they say that this job requires ten man-months (or “person-months” as they are called today). Simple arithmetic shows that if you allocate twenty people to that same job, if should be finished in half that time. I guess this kind of logic must be right in some sort of projects, because otherwise, economists wouldn’t have been so fond of it.

In the world of software design, however, this premise is an outright fallacy. There is no gentler way to put it. A program that can be crafted by one programmer in two months will probably take two programmers three months to complete. As far back as 1975, when software engineering was a very young profession, Frederick Brooks keenly observed that the man-month concept is but a myth.

The problem with software project management back in the 70’s was that most managers were educated in the fields of economics rather than computing, and many of the theories they were familiar with were simply not applicable to software projects. In fact, there were no equivalent theories for software design projects. And since even today, most software projects are never released on schedule, we have a bold indication that this problem, along with many other problems that Brooks outlines in his book, is still unsolved.

In the preface to the 20th Anniversary Edition, Brooks writes:

To my surprise and delight, The Mythical Man-Month continues to be popular after 20 years.

Actually, this is really a shame. It indicates that in twenty years, the software industry hasn’t learned some serious lessons, and it is still paying the price. Software engineering is still considered to be more of a strange art than an engineering profession. Truly, I would be the first to admit that there is art in software writing. It is a beautiful, delicate art that can be appreciated only by others versed in the same art. It is, I believe, a more fascinating art than architecture, more arresting than painting, more thought-provoking than music, when done by a true coding artist. However, an architect will not let the artistic aspect of designing of a house distract him from assuring that the house will withstand at least minor earthquakes. This realization is yet to dawn on most software professionals, those who consider themselves artists only and refuse to refer to themselves as engineers (an interesting solution was suggested by a good friend of mine, who considers himself a “software architect.”)

Brooks’ work is simply a must to anyone who considers a profession in the software business, and doubly-so for would-be managers in this field. The book not only outlines the problems, but also suggests some interesting solutions (“The Surgical Team,” for example). It outlines some very important pitfalls (like the “Second System” effect) that every professional in the field should be aware of. And finally, it provides many important insights and case studies.

Most of the material in the book is as relevant today as it was when originally written. Understandably, though, part of the material is outdated. In the 20th Anniversary Edition, rather than update the original text, which is considered “classical,” Brooks has wisely decided to add update chapters. These discuss the issues presented while shedding fresh light from the 90s on them. Personally, I recommend reading the relevant parts of Chapter 18 after reading each previous chapter. Chapter 18 is titled, “Propositions of The Mythical Man-Month: True or False?”, and it contains updated information about each of the chapters from 1 to 17.

Finally, this new edition includes a reprint of Brooks’ famous essay, “No Silver Bullet”, which was originally an invited paper for the IFIP ’86 conference in Dublin, and later published in Computer magazine. In this paper, Brooks speculated that no technology will be found, within ten years of its publication (in 1986), which will enhance the process of software development by an order of magnitude. Nine years later, in retrospect, Brooks sadly notes that he was right.

Find this book

New Reviews Notification

To receive notifications as new reviews are published, consider following the RSS feed.

[Post a comment on this review]

[Permalink to this review] [Fold all comments] [Unfold all comments]

		Matthew Johnson writes: The Mythical Man-Month in the Outsourcing Era When will Brooks write an update chapter to the book describing how the same principles sabotage outsourced software projects?
		[2] Posted on Thursday, 22 June 2006 at 2:30 GMT [Reply to this] [Permalink]

		TomB writes: Twenty people doing a job in five months is one hundred man-months, not ten.
		[24] Posted on Wednesday, 26 July 2006 at 18:51 GMT [Reply to this] [Permalink]

		Tal Cohen writes in reply to TomB: I stand corrected You are, of course, right... I've fixed the text accordingly. Thanks.
		[25] Posted on Thursday, 27 July 2006 at 18:58 GMT [Reply to this] [Permalink]

		Ravi writes in reply to TomB: Twenty people doing a job in five months is one hundred man-mont Hi Tom, Actually,you have mistaken the words said by Cohen. If it takes a month for a programmer to complete a software task then it is called one man-month. Your question is same as ''If it takes 10 minutes for a man to walk to some place, then what is the time taken by 10 men to walk the same distance?''. Obviously, it is 10 minutes only, not 1hr40mins. It's just a general sense.
		[29] Posted on Friday, 06 October 2006 at 14:07 GMT [Reply to this] [Permalink]

		Konst writes in reply to Ravi: Twenty people doing a job in five months is one hundred man-mont Right, it is 10 minutes but 100 man-minutes.
		[62] Posted on Friday, 03 November 2006 at 21:06 GMT [Reply to this] [Permalink]

		Greg Morgan writes in reply to Ravi: Twenty people doing a job in five months is one hundred man-mont You need to understand 10 people each walked 10 minutes, and when counted as a sequential set of processes, it is 100 minutes walked. Imagine it as a baton race, 10 runners running 10 minutes each. Each runner ran 10 minutes, but the entire race lasted 100 minutes.
		[83] Posted on Saturday, 27 January 2007 at 3:29 GMT [Reply to this] [Permalink]

		Keith writes in reply to Greg Morgan: Twenty people doing a job in five months is one hundred man-mont Imagine it as a baton race, organised by a game of Chinese Whispers. It will take at least 200 man-minutes, and which way were we running again?
		[359] Posted on Saturday, 17 January 2009 at 7:52 GMT [Reply to this] [Permalink]

		Jack writes in reply to Ravi: Twenty people doing a job in five months is one hundred man-mont This not the reality because 10 mens can have a very nice talk, and it can take 1hr40mins or more. So the problematic is on link beetween people. So the subject is humain, and very actual.
		[729] Posted on Sunday, 29 January 2012 at 16:04 GMT [Reply to this] [Permalink]

		Alain writes: Typo Simple arithmetic shows that ..., if should be finished in half that time. should be: Simple arithmetic shows that ..., it should be finished in half that time.
		[112] Posted on Wednesday, 28 February 2007 at 21:03 GMT [Reply to this] [Permalink]

		Tal Cohen writes in reply to Alain: Typo Corrected - thanks.
		[113] Posted on Friday, 02 March 2007 at 19:03 GMT [Reply to this] [Permalink]

[Post a comment on this review] [Back to Main Page]