Editing Pair programming (section)

==Design quality==
A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons:

# the programmers bring different prior experiences to the task; 
# they may assess information relevant to the task in different ways; 
# they stand in different relationships to the problem by their functional roles.

In an attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.<ref>{{cite book |first1=Nick V. |last1=Flor |first2=Edwin L. |last2=Hutchins |chapter=Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance |pages=36–64 |chapter-url={{Google books|KT_bpSSJBgcC|page=36|plainurl=yes}} |editor1-first=Jürgen |editor1-last=Koenemann-Belliveau |editor2-first=Thomas G. |editor2-last=Moher |editor3-first=Scott P. |editor3-last=Robertson |year=1991 |title=Empirical Studies of Programmers: Fourth Workshop |publisher=Ablex |isbn=978-0-89391-856-9 }}</ref>