I remember my very first time pair programming. I disliked it very much…
But mow I changed and I’m very happy when I have a possibility to do a pair programming
If you still don’t like it there can be 2 reasons: 1) you do something wrong; 2) you have a wrong partner (does not mean that he/she is bad person/programmer).
To fix the first you have to know about healthy pair programming styles:
The main advantages of pair programming are as follows:
The increase in the cost of development when pair programming is not 100%, as one would expect, and about 15%, which is easily compensated for by a higher code qualityand therefore lower costs for testing and support).
But mow I changed and I’m very happy when I have a possibility to do a pair programming
If you still don’t like it there can be 2 reasons: 1) you do something wrong; 2) you have a wrong partner (does not mean that he/she is bad person/programmer).
To fix the first you have to know about healthy pair programming styles:
- master-slave relationship. In this case, in the second place after the development of training is often worth less experienced programmer, as a rule, he immediately wrote the code. The second more experienced programmer, he suggests, directs, and makes recommendations. Master must not be typing at the computer! Especially if difference between experience of the programmers is big.
- on an equal footing. In this case, there are two approximately equal experience of developers, from time to time changing places;
- driver-navigator. In this case programmers choose different roles. One writes code versed in the details, and the second deals with the architecture of the code, the solution of logical problems, draws a pattern;
- Ping-Pong. A programmer writes the test, and the second – an implementation of it. After a change of roles;
The main advantages of pair programming are as follows:
- most of the errors can be detected in the coding process, but not during quality testing (QA), or during the operation of the client with the system (see. continuous verification code);
- significantly reduces the overall error rate, which is confirmed by statistical data (see. continuous verification code);
- the finished product has the best design and a smaller amount of code (see. “brainstorming” and the principle of “steam relay”);
- team will cope with the problems that arise (see. principle of “steam relay”);
- developers will learn a lot more about the system as well as the process of software development (see. trained in the field of view of the teacher);
- by the end of the project a lot of people have a deep knowledge of each of its parts;
- people learn to work together and communicate, which leads to an increase in the flow of information within the team and have a positive influence on its dynamics;
- people experience more pleasure from their work.
The increase in the cost of development when pair programming is not 100%, as one would expect, and about 15%, which is easily compensated for by a higher code qualityand therefore lower costs for testing and support).