Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #19641

Re: Pardon me for asking, but...

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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