Pardon me for asking, but...

[pat.trainor]

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?

 

[Lew]

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.

 

[David Lamb]

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.

 

[pat.trainor]

Funny!

Thanks!

 

[Arne Vajhøj]

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

 

[Joerg Meier]

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

 

[Lew]

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.

 

[Gene Wirchenko]

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

 

[bob smith]

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.

 

[David Lamb]

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.

 

[Gene Wirchenko]

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

 

[Arne Vajhøj]

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]

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

 

[Lew]

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.

 

[Arved Sandstrom]

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

 

[David Lamb]

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.

 

[Roedy Green]

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

 

[bob smith]

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


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.