Talk:The Mythical Man-Month
|This article is of interest to the following WikiProjects:|
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. --184.108.40.206 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)
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)
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. 220.127.116.11 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. 18.104.22.168 00:48, 8 September 2006 (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.
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.
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.
- 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
- 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)
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").