Paired programming in outsourcing: achieving mutual understanding with the technical specialists of the customer
Probably almost any company working in the field of IT outsourcing, faced with a situation where the project from the client are not only business users, but also technical experts. Usually, this situation complicates the implementation of the project, since the project team turns into a servant of two masters: it is necessary to fulfill the requirements of both business and technicians at the same time, and often these requirements contradict each other.
However, we will leave business users alone and focus on the technical specialists of the customer and the difficulties that they bring to the project.
Disposition : the project is completely written by “our” team from scratch within six months. At this moment, at the initiative of the customer, it was decided to start making regular (once every two weeks) reviews of the code and, in general, to check the project for compliance with the standards of code, architecture and ideology. It is worth noting that their specialists are not represented by spherical technical bosses in a vacuum, but by signor from the United States (not India, notice) that are quite adequate programmers, who write their projects along with ours.
')
Two months after the start of the regular reviews, the project found itself in a state of cold war between “us” and “them.” And the situation threatened to outgrow in real hostilities - devastating reviews of the code and formidable letters turned into a sad everyday life.
Problems emerged about the following:
1. Confrontation "we-they"
Programmers, I think, are not very fond of criticizing their code, and if they also criticize some incomprehensible overseas uncle, then God himself ordered to keep for him a piece of paper in his pocket. This is understandable: we gave birth to this code in agony and love it as a child, and then the people who did not add lines to it, suddenly say that this code is generally clumsy, poorly structured and poorly extensible. Such people are enemies, and the dispute is not appropriate here.
2. "They do not do what we tell them"
Since programmers are not soldiers in the army, they’re digging from fence to lunch, in addition to a certain style, to a certain depth, so that the trenches can be obtained from overseas architecture, they react in a certain way. Namely: to the barrel in the pocket of the first item, they immediately add a second, smiling innocently at the same time. And, of course, continue to do in their own way.
In addition, I do not know how our American colleagues imagined us. I hope we didn’t think that we are coding, sitting under birch trees, drinking 100 grams of vodka (timlid - 200 grams) every half hour, and the bears playing to us on the balalaika “Oh, my box is full…”. But definitely our unwillingness to fulfill their direct orders did not change the opinion of our adequacy for the better, if only because they:
a. Customers
b. They put forward logical requirements from their point of view and proven experience
c. Still, Americans :)
3. “ Lost in Translation ”
Among domestic technical specialists, the number of people able to communicate freely with foreigners is not as great as we would like. Anyway, as I noted, programmers can be fluent in 5 programming languages, but they can even treat their native language with disdain, using the notorious "girls" and "doing" without wincing. Needless to say that the calls to learn English did not lead to anything? That is why attempts to explain to American colleagues some complicated architectural solutions came to a standstill more than once or twice. However, even less complex subjects of discussion were often given with difficulty.
When the problems listed above became obvious, there was a need to look for ways out of this situation. I saw two of them:
1. Repressive-punitive - just get the team to fulfill all the requirements of client programmers. However, in my experience, similar measures with programmers work extremely poorly and very briefly. In addition, all parties remain unhappy as a result.
2. The path of mutual understanding is to try to understand them, bring your ideas, search for compromises where it is possible. It sounds like a utopia, this does not happen, but we decided to try.
Actually, mutual understanding and we decided to look for using pair programming . Of course, the task of “luring” overseas colleagues into pair programming is not in and of itself easy, but if it succeeds, the results promise to be remarkable. In any case, we did it really well.
Solution : I’ll first briefly discuss the technological details of the process organization. For remote access to the desktop, we tried to use both Live Meeting and WebEx . Considering the fact that due to corporate security policies, our colleagues do not have “external” messengers, we initially had to use hands-free telephones for audio communication. It was not very convenient, so we got hold of the headsets. As a result, we stopped at WebEx, as they have special free (toll-free) numbers for audio communication, which you can call, for example, from Skype.
It is also necessary to have a text chat at hand, especially after the end of the steam session, because usually there is a lot of “not heard”, “misunderstood” and just “but another ...”
During pair programming, we tried to adhere to the following rules:
1. Programmers write code in the style of ping-pong , that is, first one writes a test, the second - the implementation, and then switch roles.
2. In the process of work it is necessary to constantly discuss with a partner what you are doing or are going to do and why. If there is nothing to talk about, it means that the task was chosen incorrectly - we never took simple and obvious tasks for working in pairs.
3. Pair work must be planned so as to occupy the entire time span from start to finish. No calls, meetings, etc. should interrupt the developers.
We now turn to how this approach has affected our problems described above:
1. Confrontation "we-they"
With the help of pair programming, we managed to destroy the attitude of our American colleagues towards our code as someone else’s, and our programmers stopped seeing them as “left-wing” uncles who can only criticize indiscriminately, without really delving into the essence, since now the code was written by us, and they. Indeed, when a part of the code is written with his own hand by the people who make the review, then a completely different attitude to it is formed. Moreover, we occasionally found ourselves in a situation where one of the Americans began to criticize the code, which, as it turned out, belonged to his compatriot. In such cases, we could only rub our hands together, listening to the “picker” explain that he is wrong, much more colorful and more colorful than we would have :)
2. "They do not do what we tell them"
If earlier, at the end of the review of the code, we had a list of changes, which we somehow tried to implement with grief, skipping points that we thought were pointless, and doing the rest according to our understanding, now we had the opportunity to work on this list together with our overseas colleague . So, we could clarify all the details, discuss the difficulties that prevent the implementation of certain items and so on. Accordingly, they were able to explain the reason for the emergence of a particular requirement for the architecture or code. As a result, we realized that in most cases they were offering us completely sane things, and they stopped thinking of us as red partisans, derailing echelons with lists of their bourgeois demands and arranging outright sabotage. Have you stopped thinking that the code is under the birches? I'm not sure :)
3. “ Lost in Translation ”
As everyone understands, in third-party programming there is no place for the third, therefore, one way or another, the programmer will have to talk himself. This is not a general rally, where the manager will say everything, and the rest can get rid of OK, No, Yes, and the most joyful Bye!
On the one hand, it is much more complicated, but on the other hand, it is simpler, because before you two a piece of code is opened, and it will be mainly about it. This gives a clear and limited context and thus facilitates communication. In addition, programmer ideas are universal, and the terms are mostly English-speaking, which greatly helps mutual understanding.
After a while, I noticed two things. Firstly, when a person himself beats up a couple of times in a conversation with a foreigner, he usually becomes so ashamed that he will immediately run to learn a language. No additional incentives are needed anymore, and the courses paid by the company are not needed for nothing - instantly there is time and own money for a personal tutor. And secondly, when the spoken language is already tightened to a sufficient level, and the language barrier and the fear of communication are overcome, then there comes a continuous thrill from the fact that you are well understood by the one with whom you used to explain almost on your fingers. For some reason, a special fun happens when it turns out to be a good joke - you need to see these content lyby to the ears, when, in response to your joke, from “that” side, laughter resounds.
By the way, here I want to mention the difference in mentality that we have encountered. It is quite common for us to “complain about life”, the Americans, on the contrary, always have everything to be “good”. Following this logic, we “complained” for some time, bringing the most neglected pieces of code to the review in order to listen to tips for improvement. Naturally, they carried it all to smithereens and were terribly upset, thinking what the rest of our code was, if we brought them such a terrible gossip to the review. It took some time before it dawned on us that the review should bring the best pieces of code, and this is what is expected of us - to show how much we understand what they want from us and what we can do. After successful reviews, such parts of the code became internal standards, according to which everything was refactored later. The advice is simple: you should not show people a code that no one has ever tried to put in order, bring it at first to at least “not ashamed”, and even better - “proud”.
Total
Summing up all of the above, I would like to note that it is worthwhile to seek mutual understanding with their foreign colleagues and establish communication with them in any case. This brings many advantages, and at the same time I cannot come up with any negative side of this process, except, perhaps, time-consuming. Well, if your team considers foreign colleagues mutants and they reciprocate you, then I would advise you to do this first. It seems to me that pair programming is suitable for this purpose as well as possible. And if someone managed to use something else for the same purpose - I will be grateful if you share your experience in the comments.
However, we will leave business users alone and focus on the technical specialists of the customer and the difficulties that they bring to the project.
Disposition : the project is completely written by “our” team from scratch within six months. At this moment, at the initiative of the customer, it was decided to start making regular (once every two weeks) reviews of the code and, in general, to check the project for compliance with the standards of code, architecture and ideology. It is worth noting that their specialists are not represented by spherical technical bosses in a vacuum, but by signor from the United States (not India, notice) that are quite adequate programmers, who write their projects along with ours.
')
Two months after the start of the regular reviews, the project found itself in a state of cold war between “us” and “them.” And the situation threatened to outgrow in real hostilities - devastating reviews of the code and formidable letters turned into a sad everyday life.
Problems emerged about the following:
1. Confrontation "we-they"
Programmers, I think, are not very fond of criticizing their code, and if they also criticize some incomprehensible overseas uncle, then God himself ordered to keep for him a piece of paper in his pocket. This is understandable: we gave birth to this code in agony and love it as a child, and then the people who did not add lines to it, suddenly say that this code is generally clumsy, poorly structured and poorly extensible. Such people are enemies, and the dispute is not appropriate here.
2. "They do not do what we tell them"
Since programmers are not soldiers in the army, they’re digging from fence to lunch, in addition to a certain style, to a certain depth, so that the trenches can be obtained from overseas architecture, they react in a certain way. Namely: to the barrel in the pocket of the first item, they immediately add a second, smiling innocently at the same time. And, of course, continue to do in their own way.
In addition, I do not know how our American colleagues imagined us. I hope we didn’t think that we are coding, sitting under birch trees, drinking 100 grams of vodka (timlid - 200 grams) every half hour, and the bears playing to us on the balalaika “Oh, my box is full…”. But definitely our unwillingness to fulfill their direct orders did not change the opinion of our adequacy for the better, if only because they:
a. Customers
b. They put forward logical requirements from their point of view and proven experience
c. Still, Americans :)
3. “ Lost in Translation ”
Among domestic technical specialists, the number of people able to communicate freely with foreigners is not as great as we would like. Anyway, as I noted, programmers can be fluent in 5 programming languages, but they can even treat their native language with disdain, using the notorious "girls" and "doing" without wincing. Needless to say that the calls to learn English did not lead to anything? That is why attempts to explain to American colleagues some complicated architectural solutions came to a standstill more than once or twice. However, even less complex subjects of discussion were often given with difficulty.
When the problems listed above became obvious, there was a need to look for ways out of this situation. I saw two of them:
1. Repressive-punitive - just get the team to fulfill all the requirements of client programmers. However, in my experience, similar measures with programmers work extremely poorly and very briefly. In addition, all parties remain unhappy as a result.
2. The path of mutual understanding is to try to understand them, bring your ideas, search for compromises where it is possible. It sounds like a utopia, this does not happen, but we decided to try.
Actually, mutual understanding and we decided to look for using pair programming . Of course, the task of “luring” overseas colleagues into pair programming is not in and of itself easy, but if it succeeds, the results promise to be remarkable. In any case, we did it really well.
Solution : I’ll first briefly discuss the technological details of the process organization. For remote access to the desktop, we tried to use both Live Meeting and WebEx . Considering the fact that due to corporate security policies, our colleagues do not have “external” messengers, we initially had to use hands-free telephones for audio communication. It was not very convenient, so we got hold of the headsets. As a result, we stopped at WebEx, as they have special free (toll-free) numbers for audio communication, which you can call, for example, from Skype.
It is also necessary to have a text chat at hand, especially after the end of the steam session, because usually there is a lot of “not heard”, “misunderstood” and just “but another ...”
During pair programming, we tried to adhere to the following rules:
1. Programmers write code in the style of ping-pong , that is, first one writes a test, the second - the implementation, and then switch roles.
2. In the process of work it is necessary to constantly discuss with a partner what you are doing or are going to do and why. If there is nothing to talk about, it means that the task was chosen incorrectly - we never took simple and obvious tasks for working in pairs.
3. Pair work must be planned so as to occupy the entire time span from start to finish. No calls, meetings, etc. should interrupt the developers.
We now turn to how this approach has affected our problems described above:
1. Confrontation "we-they"
With the help of pair programming, we managed to destroy the attitude of our American colleagues towards our code as someone else’s, and our programmers stopped seeing them as “left-wing” uncles who can only criticize indiscriminately, without really delving into the essence, since now the code was written by us, and they. Indeed, when a part of the code is written with his own hand by the people who make the review, then a completely different attitude to it is formed. Moreover, we occasionally found ourselves in a situation where one of the Americans began to criticize the code, which, as it turned out, belonged to his compatriot. In such cases, we could only rub our hands together, listening to the “picker” explain that he is wrong, much more colorful and more colorful than we would have :)
2. "They do not do what we tell them"
If earlier, at the end of the review of the code, we had a list of changes, which we somehow tried to implement with grief, skipping points that we thought were pointless, and doing the rest according to our understanding, now we had the opportunity to work on this list together with our overseas colleague . So, we could clarify all the details, discuss the difficulties that prevent the implementation of certain items and so on. Accordingly, they were able to explain the reason for the emergence of a particular requirement for the architecture or code. As a result, we realized that in most cases they were offering us completely sane things, and they stopped thinking of us as red partisans, derailing echelons with lists of their bourgeois demands and arranging outright sabotage. Have you stopped thinking that the code is under the birches? I'm not sure :)
3. “ Lost in Translation ”
As everyone understands, in third-party programming there is no place for the third, therefore, one way or another, the programmer will have to talk himself. This is not a general rally, where the manager will say everything, and the rest can get rid of OK, No, Yes, and the most joyful Bye!
On the one hand, it is much more complicated, but on the other hand, it is simpler, because before you two a piece of code is opened, and it will be mainly about it. This gives a clear and limited context and thus facilitates communication. In addition, programmer ideas are universal, and the terms are mostly English-speaking, which greatly helps mutual understanding.
After a while, I noticed two things. Firstly, when a person himself beats up a couple of times in a conversation with a foreigner, he usually becomes so ashamed that he will immediately run to learn a language. No additional incentives are needed anymore, and the courses paid by the company are not needed for nothing - instantly there is time and own money for a personal tutor. And secondly, when the spoken language is already tightened to a sufficient level, and the language barrier and the fear of communication are overcome, then there comes a continuous thrill from the fact that you are well understood by the one with whom you used to explain almost on your fingers. For some reason, a special fun happens when it turns out to be a good joke - you need to see these content lyby to the ears, when, in response to your joke, from “that” side, laughter resounds.
By the way, here I want to mention the difference in mentality that we have encountered. It is quite common for us to “complain about life”, the Americans, on the contrary, always have everything to be “good”. Following this logic, we “complained” for some time, bringing the most neglected pieces of code to the review in order to listen to tips for improvement. Naturally, they carried it all to smithereens and were terribly upset, thinking what the rest of our code was, if we brought them such a terrible gossip to the review. It took some time before it dawned on us that the review should bring the best pieces of code, and this is what is expected of us - to show how much we understand what they want from us and what we can do. After successful reviews, such parts of the code became internal standards, according to which everything was refactored later. The advice is simple: you should not show people a code that no one has ever tried to put in order, bring it at first to at least “not ashamed”, and even better - “proud”.
Total
Summing up all of the above, I would like to note that it is worthwhile to seek mutual understanding with their foreign colleagues and establish communication with them in any case. This brings many advantages, and at the same time I cannot come up with any negative side of this process, except, perhaps, time-consuming. Well, if your team considers foreign colleagues mutants and they reciprocate you, then I would advise you to do this first. It seems to me that pair programming is suitable for this purpose as well as possible. And if someone managed to use something else for the same purpose - I will be grateful if you share your experience in the comments.
Source: https://habr.com/ru/post/148789/
All Articles