Most programmers are used to sit alone at a computer, and to solve their problems independently. Planning, implementation and control come from a single source. There is also the entire responsibility on the shoulders of the solo programmer. With the method of pair programming (pair programming), this burden on several shoulders is distributed as two programmers share a workstation and jointly manage the project. This principle comes from the area of extreme programming, where the completion of a project in the foreground stands - regardless of the method chosen to achieve this goal.
The main reason for the pair programming is obvious: by control should be avoided errors as far as possible in advance and excluded expensive subsequent changes. However, practical experience with pair programming have shown that this method has other benefits.
Usually, the work in mutual rhythm takes place, where the role of the found and supporter is coming to one of the two programmers, while his partner writes the code. This leads to a reduced the average 15 percent error rate compared to individual programmers, as a neutral observer is usually immediately attentive errors, which could avoid the active programmers in the workflow. The mutual control increases the general discipline, resulting in a much more effective work. So also the factor of convenience is turned off as far as possible especially when troubleshooting is always working at the proper location in your code. All program code is more efficient in this way, what smaller programs produces a better code and an average of 20 percent. In addition, team members can motivate each other and drive, which leads to much shorter breaks, fewer interruptions and a general higher work rate.
Every programmer has its areas of expertise, strengths and weaknesses. In pair programming, thus complementary partners and prevent as far as possible, that an individual developer on an unforeseen issue gets stuck. At the same time, the permanent mutual consultation ensures an ongoing exchange of knowledge. In addition to the learning effect is thus ensured that all stakeholders have the same level of knowledge with regard to the code base.
Most of the programmers who already gained experience with pair programming, said having more fun at work. Because also the occupation of programming pairs will change from time to time in larger companies, the pair programming in the distant sense even as an instrument for effective team building can be viewed. Interestingly showed also, that programming pairs are rarely interrupted by other colleagues, as a developer, sitting alone at the computer.
Of course, the pair programming is no miracle solution for every purpose. Perhaps, especially small or simple projects, it makes no sense to work together. Mutual antipathy dispute brings forth and can run the idea behind the pair programming in the opposite and paralyze the entire team. It is so very important that the partners at the human level get along, maintain a professional working environment. Also, the team members should agree on a common style of programming. Here is completely different philosophies come together and no one is willing to take others to the, a pair work probably does not make sense.
It should be noted, that the pair programming requires a certain preparation while as new partner first together gradually final and their approach must - plan but a much more effective and faster work is possible, as soon as the pair played a. Increased productivity, a lower error rate and clean codes are the fruits of successful pair programming.
“I am the founder of Majer Consulting and Majer Training and an experienced software developer, trainer and consultant. I have been on the road in the SAP world since 1998, supporting numerous projects, and have developed a passion for software engineering, software testing and agile development methods such as TDD. When I am not servicing customers or holding seminars, I am speaking at conferences or writing my next book.”