This short tutorial explains Pair Programming of Agile Scrum Development and why Pair Programming is such a good idea. It dives into the reasons why we should use Pair Programming including: built in peer review, better thought out code and better knowledge sharing. Read more
What is pairing all about? Is it only about writing code or tests, or is it more than that? Come have some fun and learn how to pair without writing code. You might even find yourself laughing and making friends. Read more
Pair Programming is a core practices of extreme programming and literally means that all production software is written by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. Read more
Saros is an open source Eclipse plugin for distributed pair programming. It allows to do collaborative text editing with support of many participants at once. All members of a session have an identical copy of an Eclipse project and Saros keeps these copies synchronized.
A discussion about pair programming at Xebia
J. B. Rainsberger and Naresh Jain demonstrate many pairing-anti-patterns.
Did you try pair programming but it didn’t work? Are you wondering if it’s worth it? In this live play you’ll follow a team as they go through stages and struggles of learning pair programming. You’ll see anti-patterns in practice so you can recognize them, and you’ll learn the small subtle things that is the difference between wasting time and a high productivity. Get the popcorn ready and open your mind. Pair programming can be a big boost – if it’s done right
Sit in like a fly on the wall, while Jim Weirich and Joe O’Brien walk through a code review. The team has uncovered some very typical issues that can arise in Ruby projects. The code review is presented in three acts. Act I is a review of a typical rails application. Having added some testing and followed the typical restful conventions, this application seems pretty solid on the foundation. As Jim and Joe demonstrate, however, the application has some areas of concern. Act II is a code review for an open source gem. The team demonstrates some critical mistakes that library writers usually make and show ways in which the code could be written in order to play nicer in the open source ecosystem. Act III is all about strategy. Now that we have identified the areas that need to be worked on, how do we go about getting there. It’s unrealistic to stop all development and rewrite the two projects. The team helps the client figure out a game plan that allows them to continue moving forward.
Pairing 101 aims to introduce what kind of activities are good for pairing and which aren’t. It will also try to explain how you can develop your skills and also explain how to be an absolutely atrocious pair.
The session is aimed at leaders in teams who are transitioning to agile / XP and are struggling to adopt pair programming. It helps participants to discover and understand the complex social factors that inhibit healthy collaboration in their teams, and to figure actions they can take to address them. I think Pair Programming is vital to the success of a programming team, but every time I join a new team I seem to find I’m in a minority of people who feel that way, let alone have any experience of actually doing it. This is not a session about convincing a manager that it’s a good idea: let’s assume he or she trusts you to do whatever is right for the project. This is about exploring, understanding and ultimately tackling the hidden influences which inhibit your peers from coming out of their caves and sharing their thoughts and ideas in regular, constructive, creative, pairing sessions.keep looking »