Pardon me for asking, but...

Discussion in 'Java' started by pat.trainor@gmail.com, Oct 26, 2012.

  1. Guest

    In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming emergency...

    Assuming such needs _are_ life-threatening, why doesn't the salary offered ever reflect this sense of urgency?
    , Oct 26, 2012
    #1
    1. Advertising

  2. Lew Guest

    wrote:
    > In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've
    > managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming
    > emergency...


    Short career so far?

    > Assuming such needs _are_ life-threatening, why doesn't the salary offered ever reflect this sense of urgency?


    You've heard of "spam", right?

    When do spammers avoid hyperbole?

    But then, your questions are certainly rhetorical.

    --
    Lew
    Lew, Oct 26, 2012
    #2
    1. Advertising

  3. David Lamb Guest

    On 26/10/2012 3:25 PM, Lew wrote:
    > wrote:
    >> In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've
    >> managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming
    >> emergency...

    >
    > Short career so far?


    Do people still read Brooks' "Mythical Man-Month"? He said "adding
    people to a late project makes it later". So if you have a programming
    "emergency", maybe hiring somebody at the last minute isn't going to
    help. Nevertheless, people seem to do it.
    David Lamb, Oct 26, 2012
    #3
  4. Guest

    Funny!

    Thanks!
    , Oct 26, 2012
    #4
  5. Arne Vajhøj Guest

    On 10/26/2012 2:47 PM, wrote:
    > In light of these job postings, what exactly constitutes an "URGENT"
    > need for a programmer? I've managed developers, and I can honestly
    > say that I've never seen-or even _heard_ of-a programming
    > emergency...
    >
    > Assuming such needs _are_ life-threatening, why doesn't the salary
    > offered ever reflect this sense of urgency?


    Job posts to usenet are usually totally clueless recruiters or
    scammers.

    Exceptions are when a regular post a link to an ad that he/she
    believe could be interesting for readers.

    Arne
    Arne Vajhøj, Oct 27, 2012
    #5
  6. Joerg Meier Guest

    On Fri, 26 Oct 2012 17:15:50 -0400, David Lamb wrote:

    > On 26/10/2012 3:25 PM, Lew wrote:
    >> wrote:
    >>> In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've
    >>> managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming
    >>> emergency...

    >> Short career so far?

    > Do people still read Brooks' "Mythical Man-Month"? He said "adding
    > people to a late project makes it later". So if you have a programming
    > "emergency", maybe hiring somebody at the last minute isn't going to
    > help. Nevertheless, people seem to do it.


    That truthism doesn't mean no project no matter how close or far from its
    deadline can ever be sped up no matter the amount of programmers added.

    Liebe Gruesse,
    Joerg

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
    Joerg Meier, Oct 27, 2012
    #6
  7. Lew Guest

    Joerg Meier wrote:
    > David Lamb wrote:
    >> Do people still read Brooks' "Mythical Man-Month"? He said "adding
    >> people to a late project makes it later". So if you have a programming
    >> "emergency", maybe hiring somebody at the last minute isn't going to
    >> help. Nevertheless, people seem to do it.

    >
    > That truthism [sic] doesn't mean no project no matter how close or far from its
    > deadline can ever be sped up no matter the amount of programmers added.


    What exactly does that assertion contribute to the discussion?

    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.

    To paraphrase Steve McConnell's /Rapid Development/, it's not that late
    addition of personnel to a project is the worst mistake one can make, but it's
    repeated so often with such predictable (harmful) results that it deserves to
    be labeled a "classic" mistake.

    You won't always lose betting against the casino, but don't back a plan based
    on beating the house.

    --
    Lew
    Lew, Oct 28, 2012
    #7
  8. On Sat, 27 Oct 2012 20:43:09 +0200, Joerg Meier <>
    wrote:

    >On Fri, 26 Oct 2012 17:15:50 -0400, David Lamb wrote:
    >
    >> On 26/10/2012 3:25 PM, Lew wrote:
    >>> wrote:
    >>>> In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've
    >>>> managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming
    >>>> emergency...
    >>> Short career so far?

    >> Do people still read Brooks' "Mythical Man-Month"? He said "adding
    >> people to a late project makes it later". So if you have a programming
    >> "emergency", maybe hiring somebody at the last minute isn't going to
    >> help. Nevertheless, people seem to do it.

    >
    >That truthism doesn't mean no project no matter how close or far from its
    >deadline can ever be sped up no matter the amount of programmers added.


    "truism".

    You can win at Russian Roulette. Nonetheless, the usual advice
    is to avoid playing.

    Lew said good stuff. Let me add that if a project is far from
    its deadline, then "URGENT" is probably not very accurate.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Oct 29, 2012
    #8
  9. bob smith Guest

    On Friday, October 26, 2012 1:47:41 PM UTC-5, wrote:
    > In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming emergency...
    >
    >
    >
    > Assuming such needs _are_ life-threatening, why doesn't the salary offered ever reflect this sense of urgency?


    Basically, they need someone to fix a Maps application so people no longer end up at Dunkin Donuts when they're trying to get to Starbucks.
    bob smith, Oct 29, 2012
    #9
  10. David Lamb Guest

    On 29/10/2012 10:09 AM, bob smith wrote:
    > On Friday, October 26, 2012 1:47:41 PM UTC-5, wrote:
    >> In light of these job postings, what exactly constitutes an "URGENT" need for a programmer? I've managed developers, and I can honestly say that I've never seen-or even _heard_ of-a programming emergency...
    >>
    >>
    >>
    >> Assuming such needs _are_ life-threatening, why doesn't the salary offered ever reflect this sense of urgency?

    >
    > Basically, they need someone to fix a Maps application so people no longer end up at Dunkin Donuts when they're trying to get to Starbucks.
    >


    In this case the fix is easy: go back to using the working 3rd-party app
    you dumped in the first place.
    David Lamb, Oct 29, 2012
    #10
  11. On Mon, 29 Oct 2012 10:38:08 -0400, David Lamb <>
    wrote:

    >On 29/10/2012 10:09 AM, bob smith wrote:


    [snip]

    >> Basically, they need someone to fix a Maps application so people no longer end up at Dunkin Donuts when they're trying to get to Starbucks.


    >In this case the fix is easy: go back to using the working 3rd-party app
    >you dumped in the first place.


    Or
    http://theamazingios6maps.tumblr.com/post/31969830493/london-tube

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Oct 29, 2012
    #11
  12. Arne Vajhøj Guest

    On 10/26/2012 5:15 PM, David Lamb wrote:
    > On 26/10/2012 3:25 PM, Lew wrote:
    >> wrote:
    >>> In light of these job postings, what exactly constitutes an "URGENT"
    >>> need for a programmer? I've
    >>> managed developers, and I can honestly say that I've never seen-or
    >>> even _heard_ of-a programming
    >>> emergency...

    >>
    >> Short career so far?

    >
    > Do people still read Brooks' "Mythical Man-Month"?


    Yes.

    > He said "adding
    > people to a late project makes it later". So if you have a programming
    > "emergency", maybe hiring somebody at the last minute isn't going to
    > help. Nevertheless, people seem to do it.


    Note that the sentence before that famous quote is:

    "Oversimplifying outrageously, we state Brooke's Law:"

    Reality is a bit more complex.

    Arne
    Arne Vajhøj, Oct 31, 2012
    #12
  13. Arne Vajhøj Guest

    On 10/28/2012 1:02 PM, Lew wrote:
    > Joerg Meier wrote:
    >> David Lamb wrote:
    >>> Do people still read Brooks' "Mythical Man-Month"? He said "adding
    >>> people to a late project makes it later". So if you have a programming
    >>> "emergency", maybe hiring somebody at the last minute isn't going to
    >>> help. Nevertheless, people seem to do it.

    >>
    >> That truthism [sic] doesn't mean no project no matter how close or far from its
    >> deadline can ever be sped up no matter the amount of programmers added.

    >
    > What exactly does that assertion contribute to the discussion?


    Well - it explains pretty well that the reality is a bit more
    complex than the single quote from the book.

    Which Brooke agrees to.

    Moving from one-liner to reality seems as a valuable contribution to me.

    > 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 does not provide empirical evidence just a made up
    example.

    And call the law for "Oversimplifying outrageously".

    I would expect any experienced software developer to have seen
    projects teams to have successfully been augmented to catch up
    with delays.

    The point in that chapter is not that project management can
    not do anything. The point in that chapter is that:

    time = effort / people

    does not hold due to several factors (tasks that are
    sequential by nature, need to train new people joining the
    team, more overhead in larger teams etc.). Which makes it
    difficult to catch up on delays by adding more people. But
    difficult is not the same as impossible.

    Arne
    Arne Vajhøj, Oct 31, 2012
    #13
  14. Lew Guest

    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 substantiatethat
    >> 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 beneither
    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
    Lew, Oct 31, 2012
    #14
  15. 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
    Arved Sandstrom, Oct 31, 2012
    #15
  16. David Lamb Guest

    On 31/10/2012 3:37 PM, Arved Sandstrom wrote:
    > On 10/31/2012 04:21 PM, Lew wrote:
    >> While Brooks called it an outrageous oversimplification, it turns out
    >> to be neither outrageous nor overly simplified.
    >>

    > 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.


    IIRC the explanation for "adding people to a late project makes it
    later" was that the original people lost more productivity in bringing
    the late people up to speed than the late people contributed. You've
    listed one (the only?) example that works because it avoids that
    fundamental problem: the new person only has to deal with a very narrow
    context, in which s/he is already expert.

    So your example contradicts the cutesy summary phrase ("Brooks' Law"),
    but not Brooks' reasoning behind it.
    David Lamb, Oct 31, 2012
    #16
  17. Roedy Green Guest

    On Fri, 26 Oct 2012 11:47:40 -0700 (PDT), wrote,
    quoted or indirectly quoted someone who said :

    >In light of these job postings, what exactly constitutes an "URGENT"

    need for a programmer? I've managed developers, and I can honestly say
    that I've never seen-or even _heard_ of-a programming emergency...

    Perhaps the "emergency" is finding someone with high enough prestige
    from sufficiently far away to tell management they are being idiots
    and have to take some substantial time out for a refactor and rethink
    or the project will NEVER complete.
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    When discusing on the Internet, anything you say is presumed to contradict
    someone else. If you are not, it is wise to explicitly state that you agree
    with or are elaborating on what someone else said. You can do this
    efficiently by starting your post with the word "Further" or "Also".
    Roedy Green, Oct 31, 2012
    #17
  18. bob smith Guest

    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, thatBrooks

    >
    > >>> 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 hepto 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.
    bob smith, Nov 6, 2012
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ronald Colijn
    Replies:
    1
    Views:
    533
    Martin Eklund
    Nov 27, 2003
  2. walala
    Replies:
    2
    Views:
    1,048
    walala
    Sep 13, 2003
  3. Pardon my stupid question...

    , May 15, 2005, in forum: Javascript
    Replies:
    2
    Views:
    117
    Randy Webb
    May 16, 2005
  4. Mark Lawrence

    [OT]Royal pardon for codebreaker Turing

    Mark Lawrence, Dec 24, 2013, in forum: Python
    Replies:
    9
    Views:
    87
    Steven D'Aprano
    Dec 28, 2013
  5. Tim Johnson
    Replies:
    0
    Views:
    60
    Tim Johnson
    Dec 24, 2013
Loading...

Share This Page