Một trong những thực hành gây tranh cãi nhất của XP là pair programming. Pair programming là việc hai programmer chia sẻ một bàn phím và một màn hình nhưng sử dụng hai bộ não của họ để viết code. Trong khi một programmer đang gõ bàn phím (và suy nghĩ về một vài dòng trong code của mình), thì programmer thứ hai đang xem code phát triển và suy nghĩ rộng hơn về nơi code có thể dẫn đến và vấn đề gì có thể gặp phải. Cặp đôi programmer sẽ chuyển đổi vai trò cho nhau thường xuyên.

Pair programming thoạt nhìn có vẻ không hiệu quả, nhưng Alistair Cockburn và Laurie Williams (2001) đã nghiên cứu và thấy rằng thực thế không phải như vậy. Họ thấy rằng mặc dầu làm tăng 15% tổng thời gian lập trình, pair programming dẫn đến:

• số lượng khuyết tật thấp hơn
• ít dòng code được viết để giải quyết những vấn đề tương tự nhau
• vấn đề được giải quyết nhanh hơn
• khi nhiều người cùng hiểu từng đoạn code thì đã làm tăng sự hài lòng trong công việc của programmer

Pair programming rất quan trọng đối với XP vì giống như nhiều thực tiễn XP khác nó yêu cầu phải có tinh thần kỷ luật cao. Chẳng hạn XP đòi hỏi  phải thực hiện công việc với ý thức kỷ luật rất cao để có thể làm refactoring mỗi khi bạn nhận thấy code có cấu trúc kém, và để có thể luôn luôn viết các bài unit test trước khi viết code. Nếu không làm việc theo cặp, bạn sẽ rất dễ dàng bỏ qua việc refactoring hoặc bỏ qua làm unit test vì suy nghĩ “chỉ bỏ qua lần này thôi có sao đâu!”

Ngay từ những trải nghiệm ban đầu, tích cực với pair programming, tôi đã bị cuốn hút. Tôi biết đó là một cách tốt để viết code. Có rất nhiều lợi thế khi làm pair programming, ngay cả đối với các team không làm việc đó 100% thời gian. Pair programming đã chứng tỏ được khả năng cải thiện chất lượng. Ngoài ra, pair programming tạo điều kiện chuyển giao kiến ​​thức và là một cách lý tưởng để đưa các programmer mới tham gia tăng tốc công việc phát triển. Nó cũng là một thực hành hiệu quả nếu bạn phải làm việc trong một lĩnh vực kinh doanh/nghiệp vụ mới mẻ hoặc khi phải giải quyết các vấn đề khó khăn của hệ thống.

Pair programming sẽ có chi phí lao động cao hơn trong ngắn hạn. Tuy nhiên, chi phí ban đầu bổ sung đó rất có thể sẽ được bù đắp nhờ lịch trình toàn dự án được rút ngắn hơn và chất lượng code cao hơn, và dẫn đến chi phí bảo trì thấp hơn. Hãy thử làm pair programming trên các mô-đun khó nhất của hệ thống và bạn hãy tự trải nghiệm xem liệu code có ít khuyết tật hơn và dễ bảo trì hơn không khi so sánh với các mô-đun tương tự từ các chương trình khác được thực hiện mà không cần pair programming.