Talk:The Mythical Man-Month

From the article...

Though Brooks does not outright say it, he clearly implies in the book that he favors contract workers by suggesting that implementors may only be hired once the architecture of the system has been completed (a step that may take several months, during which time, the implementors may have nothing to do). It stands to reason then that if written today, Brooks may have written in favor of outsourcing of software jobs in the United States to places like Russia, India, China, and elsewhere.

...but he did not write in favor of outsourcing. He wrote in favor of using programmers only when there was work for them to be done. The book contains no record of his political belief system, nor does he mention off-shore outsourcing specifically. I don't think this opinion should be assumed even if it 'stands to reason'. There is a lot of computer company outsourcing of software development within one's own country as well.

The point of the sentense should be that he was in favor of reducing cost of software development. Discussing his opinions on outsourcing without knowing his opinions on international economics, the effect on customer service or product quality is not necessary here.

I concur. Project2501a 22:31, 12 May 2005 (UTC)

The point is that the implementors shouldn't be sitting around with nothing to do while they're getting paid and wasting company money. Outsourcing or contract work is one solution to this problem. Another solution might be to have projects planned well enough that the implementors are working on another project while the architecture is being developed by other people. It's fairly common for companies to have many projects of many different sizes. If managed correctly these implementors may be doing useful work in the meantime. Also having a core team of implementors may sometimes avoid training issues that are associated with using new people. Also communication may be easier and more effective with internal workers than with foreign outsourced work. Advantages for both outsourcing or insourcing can be found. Neither approach automatically indicates that the implementors will be sitting idle while getting paid. --169.229.69.105 00:22, 23 September 2005 (UTC)

"It stands to reason then that ..." is blatant original research, i.e. an expression of the views of one editor, and the use of "may" shows that it's pure speculation. Not only had out-sourcing not been heard of at the time, but IBM had at the time the world's biggest pool of programmers, and there was always plenty of work for them to do. --Philcha (talk) 07:59, 16 January 2009 (UTC)

Surgical Team

The Surgical Team: Brooks muses that "good" programmers are generally 5-10 times as productive as mediocre ones. It stands to reason then to have a "good" programmer develop while the rest of a team provides what is needed at the right time. This is in contrast to the modern idea of extreme programming.

This seems to be a misunderstanding. I see the XP "pair programming" style as refinement of the surgical team. The core of the surgical team are the chief programmer and the co-pilot; two people who actually do programming, one stronger, one weaker. The rest is mostly occupied by tasks that were needed due to the immaturity of computer technology in the 1960s (the editor, the operator, the tool-maker), administrative tasks (which are outside the XP scope), or testing... and with a test-driven methodology, there's no place for an under-achiever there.

In other words: In XP, you completely eliminate the mediocre programmers, because there's nothing left for them to do.

I agree, I don't see the contrast either. I'm going to remove the line from the article. Teglsbo 20:23, 15 June 2006 (UTC)

I think that is a misstatement of the essay and not showing what he meant by a "surgical team" of one . Brooks started that section by denigrating managers who say they favor a small sharp team (meaning 10 excellent people). He said "this naive statement of the alternatives avoids the hard problem - how does one build 'large' systems on a meaningful schedule? Let us look at each side of the question in more detail." He acknowledges the strong differences in productivity and that communications/coordination would be easier with a small team -- but also points out that his OS/360 effort of 5000 man-years of effort would have then taken decades to produce.

His slides in CSci 780 Advanced Software Engineering (2003), presented three team structures - Democratic, where each or 5 people are connected to all others; Heirarchial, a tree-like communication between the leader over two seniro designers who each run a team of junior designers; and Surgical where all interactions go thru one central person. The team is one chief programmer who is the designer for that module, and they have a staff covering support tasks - e.g. admin to manage resources and deal with client, clerk who maintains version control (software and documents), tools smith, tester, etcetera.

Cheers Markbassett (talk) 18:23, 18 September 2022 (UTC)

RFC

Data Structure: Show me your functions, and I will be confused. Show me your data, and your functions will be obvious. What is this? Can someone please clarify this up a little more in the article? This isn't vandalism, right?

No, it's from the book.

I've been skimming through the anniversary edition (1995) but must have overlooked it. If anybody knows the page number, please add it on the article or write it here. Thanks! – Adrian | Talk 11:34, 20 November 2005 (UTC)

I have a PDF of the book's latest edition and after doing several searches I cannot find this in it. The word "data structure" is not in the book at all. I am therefore, removing this line. 193.251.135.126 15:34, 25 February 2006 (UTC)

Might I ask where you got the PDF? I'm looking for an electronic version myself. --Janto 15:28, 26 February 2006 (UTC)

the correct quote is "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." (page 102, chapter 9, "representation is the essence of programming", 1995 edition). when quoted, the old-fashioned terms "flowchart" and "tables" are sometimes replaced by "code" and "structures".

The first line mentioned here was popularised in Programming Pearls and I guess is the (much) more common version. Shabda

3 or 2?

Is this line correct:

The second system an engineer designs is the most dangerous system he will ever design, since it will be disastrously overdesigned. Thus, when embarking upon a new project, a project manager should ask for a chief architect who has designed at least three systems.

If he's suggesting the second system is the problem, why would you need a project manager who has designed at least 3 systems? Is the 3rd one necessary to see that project manager is indeed good at what they're doing and their disastrous second system was just a second system and not an example of the likely quality of their work? Nil Einne 18:39, 5 August 2006 (UTC)

Good catch by you! I just checked the book and this line is incorrect. It is 2 not 3. Here's the original line from page 58 of the book:

How does the project manager avoid the second-system effect? By insisting on a senior architect who has at least two systems under his belt.

I have updated the article as well. 202.125.143.66 00:48, 8 September 2006 (UTC)

On first impression it only made sense to me in the context of a second 'iteration' of the same system. Otherwise, why is the 'second' system of particular interest? Vis-a-vis any other number? And what is 'over-designed' anyway? 122.151.210.84 (talk) 19:40, 14 June 2022 (UTC)

mistakenly developed THEN Asserted? Unclear from the text, needs refinement.

Brooks's observations are based on his experiences at IBM while managing the development of OS/360. To speed development, he mistakenly attempted to add more workers to a project falling behind schedule. He also asserted that writing an Algol compiler would require six months—regardless of the number of workers involved.

There is either a tense problem here, or a logic problem. I assume he did not add more workers to a project and assert the compiler would take six months-regardless. Or was he more devious than I thought? I would think that the assertion was made in the book, long after the mistaken attempt to add workers. I shall change the text so that a logical progression is reflected in tense and meaning. Cuvtixo 20:08, 6 July 2007 (UTC)

Fair use rationale for Image:Mythical man-month (book cover).jpg

Image:Mythical man-month (book cover).jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 21:52, 2 January 2008 (UTC)

Cover image = La Brea Tar Pits?

The book cover looks rather like a drawing of the La Brea Tar Pits. Can anyone confirm this? Using such an image would be quite consistent with Brook's self-deprecating wit. Philcha (talk) 14:03, 16 April 2008 (UTC)

Yes, you are quite right. From the book:

Cover drawing: C. R. Knight, Mural of the La Brea Tar Pits. Courtesy
of the George C. Page Museum of La Brea Discoveries, The Natural
History Museum of Los Angeles County. Cover designer: Diana Coe.

202.125.143.65 (talk) 13:10, 27 April 2008 (UTC)

We have that image here on Commons --91.64.37.35 (talk) 20:02, 29 October 2021 (UTC):

Mistakenly added more workers

Article states: "He had mistakenly added more workers to a project falling behind schedule."

I think this needs rephrasing. "Mistakenly added more workers" suggests that he meant to do something other than add workers, but added workers by mistake -- as if he meant to order hardware and software, but got people instead.

The true intent is to assert that adding workers was a mistake, in terms of getting the results he needed. But I assume that the act of adding workers was, in itself, deliberate and not mistaken.

Karl gregory jones (talk) 21:05, 3 February 2010 (UTC)

Well it's been about two years, but this sentence was bugging me. I just rephrased it to attempt to be more clear that the workers didn't somehow show up when he misdialed trying to order a pizza. I'm not 100% satisfied with the revision's phrasing, but it seems like a good starting place. Feel free to revise. Zachlipton (talk) 09:36, 5 March 2012 (UTC)

Type of book

Hi, should this be considered an epistolary book? If not, why? —Preceding unsigned comment added by 99.162.148.90 (talk) 17:46, 12 February 2011 (UTC)

Epistolary would seem to imply a work of fiction, whereas Mythical Man-Month is very much a non-fiction collection of essays on engineering and project management. The essays aren't really in the form of letters either, but are simply just essays. So no, I don't think it would be appropriate to call it a "epistolary book." Zachlipton (talk) 09:29, 5 March 2012 (UTC)

Cost lowering

Implementers may be hired only after the architecture of the system has been completed (a step that may take several months, during which time prematurely-hired implementers may have nothing to do).

He indeed makes that point, but afterwards he clarifies that they can indeed start working in parallel (don't have thee book here so can't provide an acurate citation).

The article is also missing his defense of buying "of the shelf" *modules*/classes (not just finished applications), as well as moving to higher levels (writing "machine code instructions" vs "C++ instructions" vs "using modules").

RainCT (talk) 12:27, 26 March 2012 (UTC)

Editions refactor

I refactored how the lead handled the editions for several reasons. Basically, with a classic text, you want to explicitly set the context that there are multiple versions, so that a reader already in possession of one of these (without realizing the plurality) recognizes immediately the longer lens. — MaxEnt 18:43, 25 March 2018 (UTC)

Mythical Moth-Man

I have to admit, I knew this book for years (without reading it) and had always read the title as "Man-Moth" (as in man-insect, see Mothman), and after some embarrassment, I did a small check, and I now think this misreading was possibly intended by the author. The book is published the same year as The Mothman Prophecies. Furthermore the follow-up text uses the image of the silver bullet, which is also connected to the paranormal (werewolves). However, as I have no hard evidence for that, I just post it to the talk page. Done. :-) --91.64.37.35 (talk) 19:59, 29 October 2021 (UTC)

Just a coincidence; the timing would not work and the term "man-month" had a longer history. Brooks could not have gotten a book to print in January 1975 from the other June 1975 book. I think the term "man-month" came from the 19th century, but became common in management circa World War 2. It's resurgence in the early 1960s included trying to use it on large software efforts where Dr. Brooks found it just did not work well. The "Silver bullet" is referring to the metaphorical use meaning a simple and quick solution -- commonly a sarcastic label for many technical approaches being touted as a 'fix'. Dr. Brooks was saying in 1986 that there would not be any programming technique that would provide an order-of-magnitude improvement, and nothing in software that would keep up with Moore's law. Cheers Markbassett (talk) 18:45, 18 September 2022 (UTC)