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.
Subscribe to:
Post Comments (Atom)
Posts
4 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.
Couldn't have said it better myself.
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.
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.
Post a Comment