RE: "One person per product"

Jim,

This is why I reject the statement that the paired-programmer approach is
"controversial".

I can't imagine any "sometimers" and even a lot of today's hot-shots haven't
run into the following scenario.

After hours of furious head-scratching and incantations, one programmer asks
others to help debug a program.  After a few minutes, one person says "That
line right THAR...  ICBW, but looks like you don't want that asterix on
column 7...!"

Okay, maybe not that exact scenario, but something similar is played out
thousands of times a day.  The paired-programmer approach is nothing more
than the extension of this from the area of debugging to the area of
development.


OTOH, the paired-programmer approach WILL APPEAR controversial, because a
lot of folks are still looking for panaceas.  There are none.

So many, if not a majority of, shops will dive into this head-first (with
both feet...;-) without checking the water depth first...!  They'll ignore
the obvious:  "Obviously, this is most effective when two people have worked
together over time and have a mutual respect for each other, and know how to
get the most advantage out of each other's strengths."

They'll figure if a little of this approach is good, then it'll be better
still to pair folks 8-hours a day (or 10, 12, 14...)  Instead of using the
centuries-old methods of apprenticeship, they'll take their 2 TOP PERFORMERS
and immediately pair THEM (when this is the most difficult of pairings to
pull off), and probably give them the BIGGEST project the dept has EVER
attempted, to boot.


And they'll probably get disastrous results, as a consequence.. giving the
methodology the kiss of death...: "controversial".


I've said I've used this method with some success, and I hope the above
clearly points out that I've used it with some disastrous results, as well.
I could be havin one of those moments, but IIRC, the statistics on large
projects is that only 1 out of 4 ever get completed (not to even bring up
the question of whether the implementation was successful, or within
time/cost budgets).  If that's the case, and it wouldn't surprise me, I
don't know why anybody'd be looking for panaceas to fix the problem...  Nor
why they'd pursue revolutionary methodologies, in the hopes of finding that
panacea.


JMO.

jt



| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Jim W
| Sent: Friday, December 07, 2001 3:34 PM
| To: midrange-l@midrange.com
| Subject: RE: "One person per product"
| Importance: High
|
|
| JT,
|
| I can agree more.  Now matter how long someone's been around, there are
| times you run into something new, something complicated or
| something totally
| convoluted.  Many times it can be much more efficient for two people who
| complement each other to look at a problem and "bounce" things off of each
| other. They will usually come up with the resulting solution -
| much faster,
| and in many cases one that is better than either could have come up with
| alone.  Two individuals usually look at things from a slightly different
| angle.  This allows one to see things right away that the other
| doesn't.  I
| think this is especially true when a project "goes where no programmer has
| gone before."
|
| Obviously, this is most effective when two people have worked
| together over
| time and have a mutual respect for each other, and know how to
| get the most
| advantage out of each other's strengths.  (Not unlike your
| example.)  I have
| worked for 15 years with one of my colleagues, and from time to
| time we have
| worked together on the same project.  In most of those cases, it was when
| the project covered new territory.  A few times one of us started
| the work,
| but got nowhere fast, until we got together and started bouncing
| ideas back
| and forth.  People sometimes say that certain individuals "feed
| off of each
| other."  I think in some cases this is true.  Each one of us seems to be
| able to build on the last idea of the other.  It's like doing a big puzzle
| and being stuck, until someone grabs the piece that fell on the floor and
| puts it in, then all of a sudden things really get moving.  On
| many projects
| one of us would have much better ideas about how to present
| certian thing to
| the user, or how to handle authority issues, or communication issues, etc.
|
| One person can't always see everything.  Can't see all the angles, all the
| problems, all the solutions, etc.  IMHO (based on 20+ years exp.), two
| people who work well together are more efficient than one, and
| usually come
| up with superior results in less time overall, than either would working
| alone.
|
| It may be all it's worth, but that's my $.02.
|
| Jim Whalen
|
|
| ----Original Message Follows----
| From: "jt" <jt@ee.net>
| Reply-To: midrange-l@midrange.com
| To: <midrange-l@midrange.com>
| Subject: RE: "One person per product"
| Date: Fri, 7 Dec 2001 09:49:22 -0500
|
| I agree with most, but not all...
|
| <SNIP>
| I don't necessarily agree with the one-man approach however.
|
| <SNIP>
|
| Are there any shops out there that have more experienced and less
| experienced personnel...?  Are there any (other than 1-man shops) that
| DON'T...?!?
|
| <SNIP>
|
| I was more technical than he was, so the pairing worked real well.  I
| acknowledged his superior knowledge of the business and the
| systems, and he
| benefitted by my 38 expertise.  As long as you can find a mutual benefit,
| paired programming will work well...
|
| <SNIP>
|
| There are two basic approaches to paired-programming.  The first one I
| described is nothing more than an extension of the master/apprentice
| relationship.  Which has been used, successfully, for centuries...
|
| <SNIP>
|
| The second is a case where two people are masters, and whose knowledge
| compliments one another.
|
| <SNIP>
|
| I posted recently that I'm willing to learn from anyone who knows
| something I don't.  And that includes everyone on the planet, in some
| respect or another.
|
| <SNIP>
|
| Anyone who takes that POV can work in a paired-programmer team.
|
| <SNIP>
| jt
|
|
|
| _________________________________________________________________
| Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
|
| _______________________________________________
| This is the Midrange Systems Technical Discussion (MIDRANGE-L)
| mailing list
| To post a message email: MIDRANGE-L@midrange.com
| To subscribe, unsubscribe, or change list options,
| visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
| or email: MIDRANGE-L-request@midrange.com
| Before posting, please take a moment to review the archives
| at http://archive.midrange.com/midrange-l.
|