Pair Programming is an interesting technique of Agile Software Development. It means to program the code in pair, i.e. two programmers work on an assignment together. One writes the code, and other think the code. One who Writes Code is called Driver, who has the steering wheel in hand i.e. the keyboard. Other who Think the Code, is called Navigator or Observer. Navigator means who helps in navigation, who shows the path, who see the good or bad road ahead and also try to find the right path to move on. One who observe the every proceeding and provide a helping hand by discussing the observations for right implementation.
What does it mean to think the code? Isn't coding about typing the programming constructs in some specific language? You should be good with that language and then write the program. Isn't that all? Probably Not.
Writing something is not all about writing. It would involve much more than writing. Suppose you are writing an article in newspaper. Whatever language you use, writing this article means first to think what to write, from where to start, what to put in for right message, and right impact. It may require a lot of research, analysis and understanding of the desired topic. It may requires a lot of brainstorming also before finalizing what to write. It may need consultation with other experienced hand. Then it would need the drafting and editing or the written matter.
Similarly writing the software program is also not only about writing the code. It means much more, many things as we have written above for a new article and probably something more specific. This is what we call "Think the Code". And this is where a Navigator or Observer helps in, by doing all such things in parallel while writing the code.
We might have used pair programming one or other time while following any of the software development techniques. We (two developers) may prefer to sit together to write a piece of software. It happens sometimes when we find any part very complex, or quite vast in concepts, tricky or might be having many integration to control and so on. And we follow the same things as we mentioned above. One write the code, and other keeps thinking what should we write considering the bigger picture of the problem. One focuses on complexities of writing the code using language constructs, and other focuses on complexities of design and integration of code. So pair programming is not started with Agile Software Development only; but it is an important step of being Agile.
In this article, we shall discuss what Extreme Programming states about pair programming. It advocates the development of most of the production code in pairs. Reason is all about its benefits as we described briefly above. In more details, these are:
Any practice you follow, it should be supported and adopted by whole team. Only then you will be getting the best outcome. For example, we were working on a project which was having very complex points. Team and project environment was not supporting the pair programming for all the time. So we decided to sit in pair twice in a day. Once, to brain storm the design and implementation flow of next implementation and next to review the implementation. That was a good trade off for us in that project while enjoying some of the benefits of the pair programming.
What does it mean to think the code? Isn't coding about typing the programming constructs in some specific language? You should be good with that language and then write the program. Isn't that all? Probably Not.
Writing something is not all about writing. It would involve much more than writing. Suppose you are writing an article in newspaper. Whatever language you use, writing this article means first to think what to write, from where to start, what to put in for right message, and right impact. It may require a lot of research, analysis and understanding of the desired topic. It may requires a lot of brainstorming also before finalizing what to write. It may need consultation with other experienced hand. Then it would need the drafting and editing or the written matter.
Similarly writing the software program is also not only about writing the code. It means much more, many things as we have written above for a new article and probably something more specific. This is what we call "Think the Code". And this is where a Navigator or Observer helps in, by doing all such things in parallel while writing the code.
We might have used pair programming one or other time while following any of the software development techniques. We (two developers) may prefer to sit together to write a piece of software. It happens sometimes when we find any part very complex, or quite vast in concepts, tricky or might be having many integration to control and so on. And we follow the same things as we mentioned above. One write the code, and other keeps thinking what should we write considering the bigger picture of the problem. One focuses on complexities of writing the code using language constructs, and other focuses on complexities of design and integration of code. So pair programming is not started with Agile Software Development only; but it is an important step of being Agile.
In this article, we shall discuss what Extreme Programming states about pair programming. It advocates the development of most of the production code in pairs. Reason is all about its benefits as we described briefly above. In more details, these are:
- Driver can focus on the tactical challenges while writing the code, like language specific constructs and how to use these in best possible manner to have a best, maintainable and performing code. Navigator can focus on strategic issues, like designing and integration aspect of the code considering the bigger picture of whole project requirements and architecture. So it divides the responsibilities and both performs well in respective roles. The combined result is, a high quality code.
- XP advocates continuous testing and minimal number of bugs. That means high standard of coding practices (all set by team itself). Pair programming means a continuous peer review to produce high quality of code.
- It also helps in spreading the knowledge from one end to other. It means that every developer learn from each other. When they sit together to write a piece of code, they share their knowledge during that exercise. It is about learning while producing the code (from each other). A very beautiful experience indeed!!
- It helps in having a common understanding of code among all team members, as pairs keep on changing and hence everyone becomes part of every code. Knowledge sharing occurs by default for the code base. Team own the shared responsibility for whole project and that actually makes a team.
- It instill a sense of co-ordination and co-operation in team. It might be bit different or difficult initially, but eventually they learn to work and enjoy together. It improves the team spirit and make the environment more energize.
- It helps in avoiding distractions also. You will find that you will feel less disturbance from surrounding if you are working in pair. You mostly keep involved in your pair itself. If two programmers work together, most likely, other programmers also won't interrupt them. Or if anyone interrupt, the navigator can manage that and driver can still focus on its work.
- Above all, pair programming adds more brain power to one problem. It doubles the power and two mind together as a team work better than two actually.
- All production code and test cases should be done by two programmers. Or if team is becoming experienced in this practice, let them decide when they want to program in pair and when not. Mostly once team start development in pairs, they enjoy it more than working alone.
- Programmers should keep swapping the responsibilities of driver and navigator, best if frequently but programmers should decide the frequency themselves.
- Pairs should not be fixed, rather these should be made arbitrary (may be on daily basis). Any developer can choose to have another partner if current pair is getting stuck at same problem or same kind of problems are coming again and again. Pairing with different programmer will add diversity in knowledge base and helps in better knowledge insemination in team and work.
- Workplace should be designed considering that two developers will be sitting on same desk. Seating space should be comfortable for both, and computer desk should help both to see the monitor easily.
There are few points which should be considered while implementing pair programming practice. These are:
- In beginning, team may feel uncomfortable as pair programming is a complete paradigm shift. Now someone is continuously seeing your code, as you write it. Sometimes it feels like extra pressure every time. Solution is to give it a fair time to practice. It should become comfortable in few weeks time, when we start realizing its benefits (as mentioned above).
- In pair, driver may feel like that Navigator is thinking much faster than her. It may feel like, I am thinking slow and hence a feeling of comparison starts coming. However, here we need to counsel that it is not that anyone is thinking faster. Rather it is Navigator job to think and to think faster; so that driver can drive on smooth path without hurdles. Moreover, if one partner is more experienced and hence thinking fast or better, that it should be taken as a chance to learn. Pair programming is a good tool for continuous learning for both junior and seniors. Junior learns from senior what they grab with experience. Senior learn from juniors about many implementation level things which they might have forgotten or which are new for them also. Focus should be on learning, and on producing quality code.
- Sometimes navigator feels like driver is making too much mistakes in coding, and hence she wants to take the keyboard and do the programming herself. Manage to avoid this feeling, or at least delay it. You will get chance when pair will swap the positions. Or still if you can not control, ask to swap the position early. Eventually you will learn to focus on navigator job, rather than to focus on driver work.
- You may feel sometimes that current work is not for two, like you need to explore some topic or need to work for spike solution (a brief prototype or research). Pair should take a decision and may decide to work independently for that work. Once you understand the importance and benefit of pair programming, it is all about team decision then, .
- Team may need to learn more about communication skills. While you are working as observer, you may continuously entering in private space (considered to be) of another programmer in coding. If you want to suggest something there, then communication skills will play a very important role. Some may welcome the frank and direct feedback, other may not. Everyone has different level of tolerance. So members need to learn how to communicate in pleasant way while giving suggestions and contributing to the overall output without hurting anyone.
There are few negative views about Pair Programming. Try yourself - are these negative for you also:
- It might be considered as waste of time when two developers are sitting having one keyboard. However, if we experience and accept the benefits as mentioned above, we realize that coding is not about writing all the times; rather it is much more than that. Thinking is an important part of programming. Actually pair programming saves the time by avoiding the bugs which later consume much more time in identification and then in rectification - all because of continuous and dedicated job of Navigator to think the code.
- Pair programming might be considered as attack on privacy of programmer. However, it is not like that always. XP suggest, pair programming can not be implemented if a member does not support it. It should not be forced. We can only ask member to try it for few weeks. After few weeks, if she still disagree, it should not be forced. Moreover, once team gets mature in agile practices, they become mature to take decision when they want to program in pair and when independently.
Overall pair programming is a nice and interesting practice which can improve the quality of code, can make some implementation much faster and perfect, can make a group of developers - a team. Worth to try it once!! Try and share your experiences.
0 comments:
Post a Comment