Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #19576
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2012-10-31 12:21 -0700 |
| References | (1 earlier) <469d50eb-cc9b-4878-8195-1faccd60cc07@googlegroups.com> <k6euic$15t$1@dont-email.me> <1jzybo22hj28q$.12rjsy7z5zl4a.dlg@40tude.net> <61587d11-e729-4fb2-9e5e-28d9725c5280@googlegroups.com> <509095b9$0$286$14726298@news.sunsite.dk> |
| Message-ID | <7841923e-f4f4-4f4f-998d-709142c2b7b8@googlegroups.com> (permalink) |
| Subject | Re: Pardon me for asking, but... |
| From | Lew <lewbloch@gmail.com> |
Arne Vajhøj wrote: > Lew wrote: >> It is such an overwhelmingly bad idea to throw staff into the middle of a >> programming team in the middle of a project, with such consistently negative >> results when tried as has been objectively verified for decades, that Brooks >> is not the only one to offer the advice to avoid it, nor to substantiate that >> advice with evidence. > > Actually Brooke [sic] does not provide empirical evidence just a made up > example. > > And call the law for "Oversimplifying outrageously". Well, all right. Others have provided evidence. See McConnell's /Rapid Development/, for example. There's an exception to every rule, except this one. While Brooks called it an outrageous oversimplification, it turns out to be neither outrageous nor overly simplified. It has been observed consistently in the decades since /Mythical Man Month/'s publication that adding people late to a project tends to hurt more than it helps. Is this an essential characteristic of adding people late? Of course not, but in practice any project that throws staff into a project that's in emergency is not hep to the best practices of software project management, thus their emergency in the first place. For that most common scenario, the likelihood of such benighted management suddenly knowing how to integrate late staff additions is near enough to nil to strongly militate against betting in its favor. Theorize all you will, the practice bears out the principle. -- Lew
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Pardon me for asking, but... pat.trainor@gmail.com - 2012-10-26 11:47 -0700
Re: Pardon me for asking, but... Lew <lewbloch@gmail.com> - 2012-10-26 12:25 -0700
Re: Pardon me for asking, but... David Lamb <dalamb@cs.queensu.ca> - 2012-10-26 17:15 -0400
Re: Pardon me for asking, but... Joerg Meier <joergmmeier@arcor.de> - 2012-10-27 20:43 +0200
Re: Pardon me for asking, but... Lew <lewbloch@gmail.com> - 2012-10-28 10:02 -0700
Re: Pardon me for asking, but... Arne Vajhøj <arne@vajhoej.dk> - 2012-10-30 23:06 -0400
Re: Pardon me for asking, but... Lew <lewbloch@gmail.com> - 2012-10-31 12:21 -0700
Re: Pardon me for asking, but... Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-10-31 16:37 -0300
Re: Pardon me for asking, but... David Lamb <dalamb@cs.queensu.ca> - 2012-10-31 18:24 -0400
Re: Pardon me for asking, but... Patricia Shanahan <pats@acm.org> - 2012-11-06 12:39 -0800
Re: Pardon me for asking, but... bob smith <bob@coolfone.comze.com> - 2012-11-06 11:50 -0800
Re: Pardon me for asking, but... Gene Wirchenko <genew@ocis.net> - 2012-10-28 20:53 -0700
Re: Pardon me for asking, but... Arne Vajhøj <arne@vajhoej.dk> - 2012-10-30 22:40 -0400
Re: Pardon me for asking, but... pat.trainor@gmail.com - 2012-10-26 14:28 -0700
Re: Pardon me for asking, but... Arne Vajhøj <arne@vajhoej.dk> - 2012-10-26 20:56 -0400
Re: Pardon me for asking, but... bob smith <bob@coolfone.comze.com> - 2012-10-29 07:09 -0700
Re: Pardon me for asking, but... David Lamb <dalamb@cs.queensu.ca> - 2012-10-29 10:38 -0400
Re: Pardon me for asking, but... Gene Wirchenko <genew@ocis.net> - 2012-10-29 09:43 -0700
Re: Pardon me for asking, but... Roedy Green <see_website@mindprod.com.invalid> - 2012-10-31 16:26 -0700
csiph-web