Najbardziej interesującym aspektem w zamieszczonych wypowiedziach jest zgodność co do tego, że programowanie w parach nie jest złotym środkiem i nie warto programować w parach przez cały czas pracy, bowiem występują czasami zadania na tyle łatwe, że programowanie w parach jest po prostu nieefektywne. Patrząc na zamieszczone w wątku przykłady, takie jak tworzenie prostych widoków, wydaje mi się to bardzo rozsądnym argumentem.

Poruszony został także temat ping pong programming, o którym pisałem także w poprzednim poście. Jak widać z wypowiedzi, wiele osób chwali sobie wykorzystanie tej praktyki w celu nauczania w zespole TDD, które nie tylko moim zdaniem jest bardzo trudne w obyciu i wymaga dłuższego okresu nauczania.

Jimmy Bogard wspomniał również o wykorzystaniu par w procesie projektowania. Z mojego doświadczenia wynika, że jest to bardzo skuteczna metoda. Należy jednak zwrócić uwagę na to, że projektowanie w metodologiach zwinnych eliminuje tak zwanny „upfont design” poprzez  nieustanne  projektowania. Stosując więc projektowanie w parach każda para rozpoczynając implementację kryterium akceptacyjnego tzw. „user story„, korzystając na przykład z UMLa, może wyznaczyć i przedyskutować proponowaną przez nią architekturę. Największą zaletą tego rozwiązania moim zdaniem jest to, że zostaje wymuszany proces projektowania, które często zostaje pomijane w przypadku, gdy nad danym zadaniem pracuje tylko i wyłącznie jedna osoba. Poza tym mam nadzieję, że każdy jest świadom tego, „że co dwie głowy to nie jedna” i w efekcie końcowym zapewnia to, w stosunkowo krótkim czasie, powstanie „lepszej” architektury. Projektując w parach żadna z zaangażowanych osób się nie nudzi, o czym nie zawsze można powiedzieć w przypadku większej liczby osób. Oczywiście występują również sytuacje, w których wymagany jest udział większej liczby osób, gdyż dyskutowane rozwiązanie nie dotyczy tylko jednego kryterium akceptacyjnego. Tych faz projektowania jest jednak stosunkowo mało.