In the book “Pair Programming Illuminated”, Laurie Williams and Robert Kessler describe pair programming as a programming style in which two programmers work side by side on a computer, continually collaborating on the same design, algorithm, code, and test.
Pair programming is also considered an Agile software development technique originating from Extreme programming (XP).
The two programmers share a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver” ; he writes the code. The other person is the “Navigator” who reviews each line of code as it is typed, checking for errors. You may switch between roles slower or faster, depending on your context.
Ideally, the two people would be equally skilled and would each have equal time at the keyboard.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
Pair programming can be easy to use when you are focusing on building software that is of high quality. You, as a programmer, can pair with other programmers to find quicker solutions to your problems and get better results. Furthermore, you can pair with other colleagues: testers, analysts, (dev)ops, security, and so on.
Pair programming is a collaborative effort that involves a lot of communication. The idea is to have the driver and navigator communicate, discuss approaches and solve issues that might be difficult for a single developer to detect.
You can use pair programming for many different tasks. Typically, we pair program naturally when we are stuck and ask for a colleague's help. Also, we can schedule pairing sessions as a regular activity. Some like to pair daily, or just a few times per week. It's a matter of context and where it helps you get better results.
Usually, you pair program in the office, at your desk, or at your colleague's desk. You can take your laptop(s) and pair in a meeting room on a big screen, or on a terrace when the weather's nice. Or, you can remote pair program by using specific tools to pair with people wherever in the world, as long as they have a good internet connection. The collaboration between developers can be done in person or remotely. Indeed, with the changes in the way people work and the increase of remote work, more and more developers are doing pair programming sometimes hundreds of miles away.
The following timeline of verifiable sources does suggest that pair programming, in its modern form, has been around since well before the Agile movement.
People have advocated and practiced pair programming for decades, long before it was ever called pair programming. Fred Brooks, author of The Mythical Man-Month (1975), has communicated: “Fellow graduate student Bill Wright and I first tried pair programming when I was a grad student (1953–1956). We produced 1,500 lines of defect-free code; it ran correctly on the first try”.
In the early 1980s, Larry Constantine, author of more than 150 technical articles and 16 books, reported observing “Dynamic Duos” at Whitesmiths, Ltd., producing code faster and more bug-free than ever before. He commented that the code benefited from the thinking of two bright minds and the steady dialog between two trusted programmers. He concluded that two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quality.
Based upon research findings of the Pasteur project (a large sociological/anthropological study of 50 highly effective software development organizations) at Bell Labs Research, James Coplien published the “Developing in Pairs” Organizational Pattern in 1995. Coplien identified the forces of this pattern as “people sometimes feel they can solve a problem only if they have help. Some problems are bigger than any one individual.” The proposed solution of the organizational pattern is to “pair compatible designers to work together”
Create your free account and start collaborating right away with your team on all your apps. Should you have any questions about our offers, be sure to contact us.
