InfoQ Homepage Pair Programming Content on InfoQ
-
Pair Programming: Side-by-Side or Face-to-Face
Pair programming is an agile software development technique in which two programmers work together at one workstation. The benefits of pair programming are well known and the technique is widely practiced. However, what is the best way to sit while pairing?
-
How Pair Programming Really Works
Stuart Wray wrote a paper analysing how pair programming actually works in team environments and identifies four mechanisms that can be applied to improve the effectiveness of pair programming, and why it results in better quality products.
-
Opinion: Pair Programming Is Not For The Masses
Pair Programming continues to be one of the most debated and controversial practices of recent years. Most proponents don't falter in their praise of the benefits, but many of even these same people will admit they struggle to get pairing really going in their shops. Why? Obie Fernandez opinions 10 reasons why this might be so.
-
PairWithUs: On-Demand Agile Software Development Video Examples
One thing well known by most programmers is that the best (only?) way to learn programming technique is by example; specifically, watching someone else doing it. Antony Marcano & Andy Palmer's 'PairWithUs' gives people a great place to do just that.
-
How to Transfer Knowledge in an Agile Project
Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.
-
A Dollar Value On Pair Programming
"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.
-
How TDD and Pairing Increase Production
"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.
-
Models of Apprenticeship
Uncle Bob Martin recently wrote about his experience with apprentices and what he considers key to progressing from apprentice to journeyman. He describes two hypothetical apprentices: Sam, a developer who has apprenticed with the same master and had the same year fifteen years in a row. Jasmine has changed jobs (and therefore masters) a number of times - growing her skills along the way.
-
Article: Successfully Adopting Pair Programming
Jay Fields presents several concrete strategies to go from "I think pair programming is a good idea" to "our team is successfully practicing pair programming and loving it!" He covers everything from pairing stations (the physical layout of your office space), to coaching tips, to common mistakes that those new to pair programming make.
-
Pair Programming vs. Code Review
Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the agile vs. lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review. Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs.
-
Burn Stories Not Tasks
Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: "Do stories as a unit, not broken into tasks."
-
Handling Your Team's "Rotten Apple"
Recently there has been an active discussion in the Scrum Development Yahoo Group about handling an "under-performing" team member. In the 130+ response thread, "Rotten apple in Scrum team", talk ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.
-
A Journeyman's Pair Programming Tour
Corey Haines has embarked on a unique personal "Pair Programming Tour". Now three weeks into this innovative journey, Haines has posted video interviews revealing many of the unique insights he's gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.
-
Integrating Testers on to the Agile Team
What is the role of testers on an Agile team? What is their day to day experience like? What lessons have they learned
-
Stories of Scrum Adoption in China
This recent inquiry, by InfoQ China editor Jacky Li, looked at five very different cases of Scrum adoption in China, which got different results. He asked: Why did you use Scrum? How did you adopt it? What problems did you encounter, and why did it succeed or fail? Despite the small sample size, it's an interesting comparison, pointing out that improvement doesn't ensure success.