Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Pardon me for asking, but...

Reply
Thread Tools

Pardon me for asking, but...

 
 
Gene Wirchenko
Guest
Posts: n/a
 
      10-29-2012
On Mon, 29 Oct 2012 10:38:08 -0400, David Lamb <(E-Mail Removed)>
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...93/london-tube

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-31-2012
On 10/26/2012 5:15 PM, David Lamb wrote:
> On 26/10/2012 3:25 PM, Lew wrote:
>> (E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-31-2012
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



 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-31-2012
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
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      10-31-2012
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
 
Reply With Quote
 
David Lamb
Guest
Posts: n/a
 
      10-31-2012
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.

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-31-2012
On Fri, 26 Oct 2012 11:47:40 -0700 (PDT), http://www.velocityreviews.com/forums/(E-Mail Removed) 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".


 
Reply With Quote
 
bob smith
Guest
Posts: n/a
 
      11-06-2012
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
please pardon my ignorance regarding thunderbird but..... Matt Firefox 4 11-19-2006 03:17 AM
Pardon my stupid question... clifffreeling@yahoo.com Javascript 2 05-16-2005 01:39 AM
Pardon the repost..Green tinged edges on chromakey shots Gene Palmiter Digital Photography 1 07-16-2004 10:29 AM
FreeBSD - Pardon me but... Nihil NZ Computing 8 04-28-2004 05:25 AM
OT: Pardon My Intrusion - A Test bogus@nym.alias.net Computer Support 2 07-10-2003 12:50 AM



Advertisments