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

Groups > comp.lang.java.programmer > #19512 > unrolled thread

Pardon me for asking, but...

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#19512 — Pardon me for asking, but...

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?

[toc] | [next] | [standalone]

#19516

pat.t...@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#19520

On 26/10/2012 3:25 PM, Lew wrote:
> pat.t...@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#19542

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

> On 26/10/2012 3:25 PM, Lew wrote:
>> pat.t...@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#19550

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

[toc] | [prev] | [next] | [standalone]

#19570

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

[toc] | [prev] | [next] | [standalone]

#19576

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

[toc] | [prev] | [next] | [standalone]

#19578

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

[toc] | [prev] | [next] | [standalone]

#19581

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.

[toc] | [prev] | [next] | [standalone]

#19642

On 10/31/2012 3:24 PM, David Lamb wrote:
> 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.
>

I've met one other special case, once in my career. I was added late to
a project that was running behind schedule. It turned out that the
participants had made some bad basic design choices, and then charged
ahead with trying to patch up the consequences, far too busy to question
the decisions that were the root cause of the problems.

The process of stopping for a few days to explain the design to me was
highly beneficial, because it became clear that the original design
could not possibly work. Once that was recognized, it was relatively
easy to make the changes that were needed, leading to real progress.

Patricia

[toc] | [prev] | [next] | [standalone]

#19641

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.

[toc] | [prev] | [next] | [standalone]

#19552

On Sat, 27 Oct 2012 20:43:09 +0200, Joerg Meier <joergmmeier@arcor.de>
wrote:

>On Fri, 26 Oct 2012 17:15:50 -0400, David Lamb wrote:
>
>> On 26/10/2012 3:25 PM, Lew wrote:
>>> pat.t...@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#19567

On 10/26/2012 5:15 PM, David Lamb wrote:
> On 26/10/2012 3:25 PM, Lew wrote:
>> pat.t...@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#19521

Funny!

Thanks!

[toc] | [prev] | [next] | [standalone]

#19525

On 10/26/2012 2:47 PM, pat.trainor@gmail.com 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

[toc] | [prev] | [next] | [standalone]

#19553

On Friday, October 26, 2012 1:47:41 PM UTC-5, pat.t...@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#19555

On 29/10/2012 10:09 AM, bob smith wrote:
> On Friday, October 26, 2012 1:47:41 PM UTC-5, pat.t...@gmail.com 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.

[toc] | [prev] | [next] | [standalone]

#19556

On Mon, 29 Oct 2012 10:38:08 -0400, David Lamb <dalamb@cs.queensu.ca>
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

[toc] | [prev] | [next] | [standalone]

#19582

On Fri, 26 Oct 2012 11:47:40 -0700 (PDT), pat.trainor@gmail.com 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".

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web