Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #19641
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2012-11-06 11:50 -0800 |
| References | (3 earlier) <1jzybo22hj28q$.12rjsy7z5zl4a.dlg@40tude.net> <61587d11-e729-4fb2-9e5e-28d9725c5280@googlegroups.com> <509095b9$0$286$14726298@news.sunsite.dk> <7841923e-f4f4-4f4f-998d-709142c2b7b8@googlegroups.com> <n6fks.13189$Be.5831@newsfe13.iad> |
| Message-ID | <b061fdd5-0264-41d8-a1b1-91f36650f810@googlegroups.com> (permalink) |
| Subject | Re: Pardon me for asking, but... |
| From | bob smith <bob@coolfone.comze.com> |
On Wednesday, October 31, 2012 2:37:57 PM UTC-5, Arved Sandstrom wrote: > On 10/31/2012 04:21 PM, Lew wrote: > > > 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. > > > > > There's one exception, and I've seen it often enough. The emergency may > > simply be because the project, despite decent management and otherwise > > adequate staffing, runs into a showstopper problem in a single spot, > > say. Maybe a 3rd party library has behaviour not completely in keeping > > with its announced API - I've seen that more than once. Maybe the suite > > of defects associated with a given app server is presenting a really > > thorny obstacle for a specific scenario. Maybe - this is a big and > > common maybe - the team didn't know what they didn't know, at the > > fringes and niches of a given framework...at the 11th hour they discover > > that there's just that one last bit that they were unaware of. > > > > In all these circumstances a late addition of one or two SMEs can help, > > and often does. > > > > I don't think Brooks was talking about the late addition of expert > > technicians like this. But it is nonetheless a late addition of staff > > that does often help. > > > > AHS There's another exception as well. When the number of people working on a project is 0, adding more people doesn't make it later.
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