tag:blogger.com,1999:blog-24947835.post1373160727187045512..comments2023-10-24T07:07:25.779-04:00Comments on Syed Rayhan on Technology and Business: Pairing or Pair Programming "XP Style" on a Story?Syedhttp://www.blogger.com/profile/00555014429818429040noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-24947835.post-2796513632190967812009-03-06T17:15:00.000-05:002009-03-06T17:15:00.000-05:00hi,thanks for nice writeup.we used to team up with...hi,<BR/>thanks for nice writeup.<BR/>we used to team up with small group of programmers, designers and qa persons (5 to 6 persons). so we can't always take advantage from pair programming. but most often we pairing two persons to remove impediment. <BR/><BR/>like you said, assisting fellow programmers is one of our basic instincts. but i belief you can't easily achieve pair programming advantages by practicing this over night or month. it should take few more times to understand the real importance to those who will write code holding a pair of extra eyes on his own shoulder. even i don't think mix expertise could always come up with better pair. <BR/><BR/>since less experienced and experienced might have different way of solving the problem also different way to write them in code. rather if you have similar expert guys who broadcast and tune their antenna in the same frequency. that might help them to boost their productivity. <BR/><BR/>i belief, if you could setup up this kinda pair 1 or 2 (similar expert) that might bring magic on your project.<BR/><BR/>obviously for training purpose you could set up pair, but not obviously for mission critical project or not even for those project where sprint performance is very important. no dela dala kaz. <BR/><BR/>best wishes,Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-24947835.post-800340530868304322009-03-03T21:14:00.000-05:002009-03-03T21:14:00.000-05:00Jeff,Helping a fellow developer out by sitting nex...Jeff,<BR/>Helping a fellow developer out by sitting next to him coding with him is what I call natural pair programming. We do not have to enforce it. We developers were doing that for ages now.<BR/><BR/>What I am suggesting is not "pair programming." And I agree with you. I call it "pairing" or collaborative coding on the same story. That is two or more developers are breaking a story into tasks and each taking on tasks and collaboratively implementing the story. <BR/><BR/>So, I am not espousing "pair programming XP style". <BR/><BR/>SyedAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-24947835.post-33306270591162919462009-03-02T01:07:00.000-05:002009-03-02T01:07:00.000-05:00stoppair programming meets the biggest resistance ...stoppair programming meets the biggest resistance from developers and project managers alike.<BR/><BR/>The project I'm currently on is doing pair programming, and to be honest it doesn't always work all the time. But I see a huge benefit in leveraging "partial pair programming"<BR/><BR/>-enforce at least 2 hours of real pair programming a day.<BR/><BR/>-when a developer is stuck for any reason, callout for a pair, other developers should be made aware that helping the pair is more important than doing one's own work.<BR/><BR/>Why?I I have found pair programming to be the best way to enforce common coding norms, alignment to common design, share knowledge, ensure there is no one single developer you can't afford to loose etc.<BR/><BR/>Your approach while reasonable, is what I call regular team coordination, and while there's nothing wrong with it, it's not pair programming, not even close...<BR/><BR/>My advice to everyone out there is to actually get on a project and experiment with it, you may or may not elect to go with it, but it's worth a real evaluation.<BR/><BR/><A HREF="http://agileconsulting.blogspot.com/" REL="nofollow"> Jeff Anderson</A>Jeff Andersonhttps://www.blogger.com/profile/17502868241692630528noreply@blogger.com