Pair programming is one of the original practice of eXtreme programming, but it is also one of the least used by Agile software development teams. In his blog post, Alisdair McDiarmid explains how Customer.io uses pair programming with remote teams.
This presentation examines the latest theories from psychology and how they throw new, interesting and sometimes frightening light on the tools, techniques, process and practices that are often the dogma of modern software development.
Pair programming is a well known practice for closely connected teams, but can it work for distributed teams as well? This talk demonstrates remote pair programming in practice and cover the benefits and drawbacks of a distributed agile programming team. How much will being distributed cost your team, what can you regain from remote pair programming and how does remote pair programming feel compared to normal team work?
Scrum requires that members of the team collaborate. One of the agile software development practice used to collaborate is pair programming. In his blog post, Erik Brickarp reports his experience when pairing a programmer and a software tester.
Pair Programming is one of the eXtreme programming (XP) original practices. Continuously in surveys about Agile, it is one of the least used Agile practices. In this blog post, Dave Nicolette do an extensive survey of pair programming trying the question: “does pair programming work?”.
In this article, Gunther Verheyen explains that pair programming is a good software development practice. Even if Scrum doesn’t prescribe specific engineering practices, Scrum fully supports the agile principle that says “Continuous attention to technical excellence and good design enhances agility”.
Pair Programming is an Extreme Programming (XP) practice where two developers collaborate on the same code on one workstation. In this blog post, Yan Pritzker provides an experience report after his first nine months of pair programming. On the positive side of pair programming, he lists quick knowledge transfer, improved productivity and higher quality code. The disadvantage of this practice are a tired voices, difficulty to research and learn, need for space for creative activities, longer time spent on trivial tasks, possible issues with sharing the same configuration for the development environment. His conclusion is that “pairing coupled with an extremely pragmatic approach to knowing when not to pair is the key to success.”