My Stuff
Email
Twitter
Front Page
Presentations
Projects
Music
Favorite Quotes

Respect
Vincent Foley-Bourgon
Sam Griffith
LeRoy Mattingly
Colin Putney
Matt Secoske
Sam Tesla
Andres Valloud

Admiration
Leo Brodie
Avi Bryant
Alan Cooper
Steve Dekorte
Stephane Ducasse
Doug Engelbart
Eric Evans
Brian Foote
Martin Fowler
Paul Graham
Dan Ingalls
Alan Kay
John McCarthy
Steve McConnell
Peter Norvig
Niall Ross
Randall Smith
Gerald Jay Sussman
David Ungar
Rebecca Wirfs-Brock
...And So Many More...

My Amps
Squeak
JavaScript
Scheme
Java
Corman Lisp
Ruby
Dolphin Smalltalk
Cincom Smalltalk
Self

Archives
05/01/2003 - 06/01/2003
06/01/2003 - 07/01/2003
07/01/2003 - 08/01/2003
08/01/2003 - 09/01/2003
09/01/2003 - 10/01/2003
10/01/2003 - 11/01/2003
11/01/2003 - 12/01/2003
12/01/2003 - 01/01/2004
01/01/2004 - 02/01/2004
02/01/2004 - 03/01/2004
03/01/2004 - 04/01/2004
04/01/2004 - 05/01/2004
05/01/2004 - 06/01/2004
06/01/2004 - 07/01/2004
07/01/2004 - 08/01/2004
08/01/2004 - 09/01/2004
09/01/2004 - 10/01/2004
10/01/2004 - 11/01/2004
11/01/2004 - 12/01/2004
12/01/2004 - 01/01/2005
01/01/2005 - 02/01/2005
02/01/2005 - 03/01/2005
03/01/2005 - 04/01/2005
04/01/2005 - 05/01/2005
05/01/2005 - 06/01/2005
06/01/2005 - 07/01/2005
07/01/2005 - 08/01/2005
08/01/2005 - 09/01/2005
09/01/2005 - 10/01/2005
10/01/2005 - 11/01/2005
11/01/2005 - 12/01/2005
12/01/2005 - 01/01/2006
01/01/2006 - 02/01/2006
02/01/2006 - 03/01/2006
03/01/2006 - 04/01/2006
04/01/2006 - 05/01/2006
05/01/2006 - 06/01/2006
06/01/2006 - 07/01/2006
07/01/2006 - 08/01/2006
08/01/2006 - 09/01/2006
09/01/2006 - 10/01/2006
10/01/2006 - 11/01/2006
11/01/2006 - 12/01/2006
12/01/2006 - 01/01/2007
01/01/2007 - 02/01/2007
02/01/2007 - 03/01/2007
03/01/2007 - 04/01/2007
04/01/2007 - 05/01/2007
05/01/2007 - 06/01/2007
06/01/2007 - 07/01/2007
07/01/2007 - 08/01/2007
08/01/2007 - 09/01/2007
09/01/2007 - 10/01/2007
10/01/2007 - 11/01/2007
11/01/2007 - 12/01/2007
12/01/2007 - 01/01/2008
01/01/2008 - 02/01/2008
02/01/2008 - 03/01/2008
03/01/2008 - 04/01/2008
04/01/2008 - 05/01/2008
05/01/2008 - 06/01/2008
06/01/2008 - 07/01/2008
07/01/2008 - 08/01/2008
08/01/2008 - 09/01/2008
10/01/2008 - 11/01/2008
01/01/2009 - 02/01/2009
09/01/2009 - 10/01/2009

Feed

Add this feed to a running copy of BottomFeeder

Saturday, October 11, 2008

Forced Pairing

 
Let's be honest. I'm not a big fan of "forced" pairing. I believe in active collaboration between cooperating team members. In other words, two people should pair if they want to. The energy of pairing is incredible when both partners are engaged and having fun. The code is better and so is the resultant design. It's the other side of the coin that I don't like and think the results are worse, even if the two programmers were working separately. A good pairing starts with the pair liking to work with one another. They don't have to see eye to eye, but they must enjoy the journey of working on code together. They will push and encourage each other to do better. A fun competition that will result in another problem being pushed past and the winner being a well-maintained system.

"Forced" pairing is what XP advocates and I see a huge problem with it. The reason is if the pair doesn't like or respect one another, the code quality will be on par with that of the worst of the pair. When pairs don't get along, one side will disengage. When this happens, you get none of the benefits. The team still thinks its safe from doing code reviews because they had four eyes on all code. Not so. To ignore the effects of "forced" pairing is to ignore that the team is human.

Labels: ,


Comments
  • Pairing assumes that two people working on the problem is the best way to proceed. Often even if the two like their pair partner it's not the best use of their skills nor time.

    The blind assumption that agile pairing will result in success, or more success, that the individuals working alone is a very big assumption and often false.

    Many people do their best thinking alone. Maybe they are inspired or get an idea within a team framework but the execution for them is best done alone. Working with someone to refine their initial work is often the best time to introduce another pair of eyes or even a whole group of many eyes.

    Often the extra eyes are needed for assistence with aspects of design, or with debugging or refinement. Often the extra eyes get in the way and prevent progress.

    Maximizing the genius of the people on your team can be a valuable asset. Applying the blind hammer of blunt instruments like the agile methods can be highly counter productive.

    As a professional programmer, systems analyst and designer, and producer of products it's important to know when to seek out others for assistence. To force it upon the process and team members is highly unwise.

    Working together with other professionals on many projects I always attempt to maximize the best of working alone and working together with the rest of the team. The key is knowing what is best for your productivity and for the team's productivity in producing the results that are aimed for.

    There is an "I" in "team" after all and it's known as the intelligence of the individual.

    By Blogger peter, at 9:09 PM   

  • Couldn't have said it better myself.

    By Blogger Blaine, at 9:14 PM   

  • Hi, Blaine! I know you've had reservations about this. Pairing with difficult people is, well, difficult. It is tempting to opt out.

    But what better place to work out the give and take of teamwork than in the smallest possible team: the pair? Anybody can work with a friend. But to work with a person who I don't naturally get along with is a chance to grow in virtue. I would not lightly pass up that opportunity.

    If two people cannot or will not work together, it seems to me one or both of them shouldn't be on the team who's standard is all production code written by pairs. Pairing is not forced, anymore than showing up for work on time is forced, because joining a team is voluntary.

    By Blogger Alan Wostenberg, at 2:26 PM   

  • I think both points are good. Human nature is certainly something to be tuned into. "Virtue" as Alan put it is also a worthwhile investment.

    I see so much value that comes from pairing that I tend to move in that direction, but I also prefer many times to work alone, allowing ideas to form, etc...

    Team make-up is probably key. At the end of the day, I suppose the wisest of us will employ that which delivers the most value to the company. That would require that each of us be open to either approach, and probably some combination of the two.

    If a pairing assignment offers little to no value, and nature forbid, negative value, then some action to correct the situation must occur.

    I think we can trust each other more than we do, so I will agree mostly with Blaine and Peter, but not entirely.

    Not pairing at all discourages engagement in the pairing activity a great deal. I find that a bit unsafe.

    Long story short, no absolutes, they just don't work.

    By Blogger Doug Stewart, at 11:35 AM   



Web hosting by ICDSoft

Metalheads Against Racism
This page is powered by Blogger. Isn't yours?


My Weekly Top 20 Artists