Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming IT Technology

The Mythical Man-Month Revisited 317

jpkunst writes "Ed Willis, over at O'Reilly's ONLamp.com, gives his varied reactions to Fred Brooks' classic The Mythical Man-Month, after 'having finally read it in its entirety'. '[...] simultaneously you can see just how much the field has changed since the original writing and just how much has stayed stubbornly the same.'"
This discussion has been archived. No new comments can be posted.

The Mythical Man-Month Revisited

Comments Filter:
  • by YetAnotherName ( 168064 ) on Friday June 18, 2004 @11:12AM (#9463170) Homepage
    Brooks put forth a lot of good ideas, some of which morphed and/or were independently discovered and some that were true then as they are today. For example, he says, "Build one to throw away." Amen to that.

    Another concept he brought to light was originally Harlan Mills's, that of making the programming team like a surgical team. A surgeon, or chief programmer, has primary architectural, design, and implementation responsibility, but is assisted by a copilot, administrator, editor, two secretaries, and a program clerk.

    While I've never seen such a team, I have witnessed pair programming that the XP (not Windows, eXtreme Programming) folks praise, and it works quite well. It may not be a full-fledged surgical team as Brooks would've liked, but the productivity of a pilot on the keyboard and a copilot following after every little mistake certainly improves productivity.
  • by Anonymous Coward on Friday June 18, 2004 @11:13AM (#9463180)
    "Maybe I'm just uneducated, or maybe it's an American thing... here in England, we probably have dozens of books that are unknown anywhere else. "

    I'm from England. I love that book and it was taught to us as a college set text. so it's not an Americvan thing ;)
  • Typo... (Score:1, Informative)

    by Anonymous Coward on Friday June 18, 2004 @11:21AM (#9463255)
    You put "bigger and better things", that should read "bigger and slower things".
  • by baywulf ( 214371 ) on Friday June 18, 2004 @11:22AM (#9463270)
    It is a very thin book but I have only skimmed through it. The name of the book basically comes from this idea...

    If you were for example painting a big house or something it my take one man two months to complete. But if you had two men then it takes one month. The more people you add the faster the job it done. So we often talk about how many man months are needed to complete a job. But that are many tasks that cannot be made faster by adding more people. Brooks states that programming is one of those tasks. Adding too many people to the programming effort will only make it take longer because of interdependencies, communication and coordination required. The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
  • by YetAnotherName ( 168064 ) on Friday June 18, 2004 @11:34AM (#9463402) Homepage
    Right. My favorite way of helping "managers" see this is by rhetorically asking, "So, why can't nine women make a baby in just one month?"
  • by Detritus ( 11846 ) on Friday June 18, 2004 @11:48AM (#9463525) Homepage
    It was OS/360.

    It's called the "second-system effect".

  • Re:A Classic Book (Score:3, Informative)

    by jbelcher56 ( 694028 ) on Friday June 18, 2004 @11:57AM (#9463618)
    It's funny you should mention this. I am finishing up my MBA (MIS concentration) and in my system analysis and design class, we studied nearly all of the topics discussed in this book. I believe the text that we used even cited many passages from this book. We then had to complete a group project, which forced us to utilize the material in a somewhat realistic setting (creating a project time tracking app). So the MBA's that want to work in technology are getting at least exposed to this. Hopefully this will make for better management, but who know's.
  • by TomorrowPlusX ( 571956 ) on Friday June 18, 2004 @01:41PM (#9464771)
    I'm talking about _The Crush_ playing in a mini window while I watched _Demolition Man_

    But then, you could simply have read my comment.
  • by Brandybuck ( 704397 ) on Friday June 18, 2004 @03:14PM (#9465796) Homepage Journal
    If you haven't read it, go read it.

    I have read this book. But that means absolutely nothing, because the upper management of my company has not read it. We're making every mistake Brooks wrote about in MMM. We're even making mistakes written about in NSB.

    We're making mistakes Brooks never dreamed of, because Brooks didn't write in a time of offshoring development. We have a CEO who truly believes that two inexperienced developers twelve time zones away are more productive than one experienced developer in house.
  • by Aron S-T ( 3012 ) on Friday June 18, 2004 @04:14PM (#9466566) Homepage
    Not too long ago I wrote an article about software development methods which heavily focused on Brooks as a precurser of Agile methods. Those who are interested can read it here [fourm.info].
  • ...not everything... (Score:2, Informative)

    by ggwood ( 70369 ) on Friday June 18, 2004 @04:27PM (#9466708) Homepage Journal
    Of course I totally agree the book is a classic, but some major portions of MMM, to my knowledge, have never gained favor, such as the surgical team analogy to working on code, where there would be like six people involved on any major code change. Certainly the man month is mythical, but IIRC that is just the early chapters. Read on and there are other things - many true, but as far as I know, many unpopular and/or untested.

    Like many great works, Brook's discription of the problem is excellent, but his attempts to solve it are not all perfect. Thus, I would not hand it to a manager to read without some preface to it.
    ____________________________________________
  • by Anonymous Coward on Friday June 18, 2004 @05:30PM (#9467446)
    ... which is a quote from the book being discussed

An authority is a person who can tell you more about something than you really care to know.

Working...