Key Concepts
The main idea behind pair programming is two developers working on a same coding module. Wherein the roles of the players may switch in fixed durations, also both players do not stand with similar compatibility and knowledge levels, i.e. one of the two would have better programming skills compared to other. This ensures that both programmers are fully aware of what the code is, how it works and why it was thought of this way.
These player's roles change fix durational hours. Generally these roles of players include driver and navigator as in the races. The driver is the primary coder, while navigator sits beside driver and perform reading, checking, some small testing, whilst thinking through problems and where to go next. So when coders lands up in a problem, now we have two people to look for the solution and not only the coder. As the code is being kept constantly reviewed by navigator, its less likely to contain bugs and hacks. Another major advantage of it is, as two people have differing specialities, these skills are transferred between each other.
Positive Aspects of Pair Programming:
1. Problem Solving - Two brains are working instead of one, so if one is doing the programming part, the other brain has already thought off the possible problems it might pop up, and thus it can start thinking for the solution as well
2. Faster Development - While one is at keyboard and coding, other can look for small typographical and silly errors, thus reducing debugging efforts and time.
3. Quality - Having input from two minds definitely improves the design process and reduces the risk of encountering mistakes.
4. Focus - Distractions like surfing on WEB, IM or emails are less likely since that would be rude to the person you are working with. Thus you can have intense focus on your goal, which is a huge difference while working alone.
The Disadvantage of Pair Programming, or rather implementing it in business, is to convince your officials for it, because "Peer Code Review" is other technique in contrast with Pair Programming can also be implemented or can say rather is in used by traditional approach. So if we have code reviewer, why would an organization like to invest more for Pair Programming. Also it demands double hours (i.e. double person for single job, though beneficial in context with effectivity), so it might be thought of as a wastage of resource.
But at the end, I personally would prefer it as a better approach compared to "Peer Code Review", yes though you can say its a waste of resource but at a long run, its NOT, because in "Peer Code Review", it needs to be well studies by someone who was out of the business during coding and thought process, so again reviewer needs to give alot of time to review, which in turn can be more waste of resource compared to Pair Programming.
The main idea behind pair programming is two developers working on a same coding module. Wherein the roles of the players may switch in fixed durations, also both players do not stand with similar compatibility and knowledge levels, i.e. one of the two would have better programming skills compared to other. This ensures that both programmers are fully aware of what the code is, how it works and why it was thought of this way.
These player's roles change fix durational hours. Generally these roles of players include driver and navigator as in the races. The driver is the primary coder, while navigator sits beside driver and perform reading, checking, some small testing, whilst thinking through problems and where to go next. So when coders lands up in a problem, now we have two people to look for the solution and not only the coder. As the code is being kept constantly reviewed by navigator, its less likely to contain bugs and hacks. Another major advantage of it is, as two people have differing specialities, these skills are transferred between each other.
Positive Aspects of Pair Programming:
1. Problem Solving - Two brains are working instead of one, so if one is doing the programming part, the other brain has already thought off the possible problems it might pop up, and thus it can start thinking for the solution as well
2. Faster Development - While one is at keyboard and coding, other can look for small typographical and silly errors, thus reducing debugging efforts and time.
3. Quality - Having input from two minds definitely improves the design process and reduces the risk of encountering mistakes.
4. Focus - Distractions like surfing on WEB, IM or emails are less likely since that would be rude to the person you are working with. Thus you can have intense focus on your goal, which is a huge difference while working alone.
The Disadvantage of Pair Programming, or rather implementing it in business, is to convince your officials for it, because "Peer Code Review" is other technique in contrast with Pair Programming can also be implemented or can say rather is in used by traditional approach. So if we have code reviewer, why would an organization like to invest more for Pair Programming. Also it demands double hours (i.e. double person for single job, though beneficial in context with effectivity), so it might be thought of as a wastage of resource.
But at the end, I personally would prefer it as a better approach compared to "Peer Code Review", yes though you can say its a waste of resource but at a long run, its NOT, because in "Peer Code Review", it needs to be well studies by someone who was out of the business during coding and thought process, so again reviewer needs to give alot of time to review, which in turn can be more waste of resource compared to Pair Programming.
1 comment:
cool, i want to do this topic next week
Post a Comment