配對機制
結對程式設計是指兩位程式設計師在同一台工作站上工作。一位程式設計師“主導”，負責操作鍵盤；另一位程式設計師“輔助”，負責觀察、學習、提問、交流和提出建議。理論上，「主導」專注於手邊的程式碼：語法、語義和演算法。 「輔助」則較少關注這些細節，而是更關注更高層次的抽象概念：例如，他們正在努力通過的測試、接下來要交付的技術任務、所有測試運行至今的時間、上次程式碼提交至今的時間，以及整體設計的品質。理論上，結對程式設計能夠帶來更好的設計、更少的缺陷，並促進開發團隊內部知識的更廣泛傳播，從而在長期來看，單位時間內能夠實現更多的功能。
傳播知識
作為一種指導機制，結對程式設計無疑是最佳選擇。如果結對雙方定期輪調（理應如此），結對程式設計就能有效率地在團隊中傳播多種知識：程式碼庫知識、設計和架構知識、功能和問題領域知識、語言知識、開發平台知識、框架和工具知識。 重構知識以及測試知識。幾乎沒有人爭論結對程式設計比傳統的程式碼審查和不太正式的方法更能有效地傳播這類知識。那麼，如此有效地傳播知識會帶來哪些生產力損失（如果有的話）呢？
結對程式設計與生產力
研究結果和一些非正式報告似乎表明，短期生產力可能會略有下降（約 15%），但由於編寫的程式碼品質大幅提升，長期生產力反而會提高。當然，這取決於你如何衡量生產力以及衡量週期。在敏捷開發環境中，生產力通常以每次迭代和每次發布實際交付的、經過測試且可運行的功能數量來衡量。如果團隊以每週程式碼行數來衡量生產力，他們可能會發現結對程式設計確實會導致程式碼行數下降（如果這意味著每個經過測試且可運行的功能所需的程式碼行數更少，那當然是好事！）。
生產力和員工流動率
結對程式設計的支持者認為，如果以足夠長的時間跨度來衡量生產力，並將人員的招募和離職納入考量，結對程式設計的價值就會更加凸顯。在許多主流計畫中，專業知識往往集中在「知識孤島」。個別程式設計師往往掌握著其他程式設計師不太了解的重要知識。如果這些知識孤島中的任何一人離開團隊，專案都可能嚴重延期，甚至更糟。結對程式理論的一部分在於，透過在團隊內部廣泛傳播各種知識，管理階層可以降低人員流動帶來的持續威脅。在極限編程（XP）中，他們提到「卡車數」：即需要有多少團隊成員被卡車撞到才會導致專案失敗。 XP 專案力求讓「卡車數」盡可能接近團隊總人數。如果有人離開，通常會有其他人接替他/她的位置。這並不是說團隊中不存在專業分工，而是說每個人都能更全面地了解專案進度。如果以團隊在多個版本中交付的功能數量來衡量生產力，那麼其生產力應該高於不進行結對程式設計的情況。
配對策略
在嚴格遵循極限程式設計（XP）規範的開發環境中，所有生產程式碼都是由結對程式編寫的。許多非XP敏捷團隊根本不使用結對程式設計。但其實在完全不使用結對程式設計和全員結對程式設計之間存在著許多中間地帶。例如，在指導新員工、處理高風險任務、新專案啟動初期（設計尚不完善）、採用新技術時，或按月或按週輪調使用結對程式設計都是可行的。允許偏好結對程式設計的程式設計師繼續使用，而允許不偏好的程式設計師不使用。雖然用程式碼審查完全取代結對程式設計的做法很流行，但我們找不到任何理由不至少嘗試一下結對程式設計。沒有合理的證據表明結對程式設計會損害團隊或項目，而且越來越多的證據表明，它是一種有益的最佳實踐。
