- Pair Programming is a software development technique which is popularized by Extreme Programing (XP) methodology.
- Pair Programming is an art which must be learnt.
Two programmers sit beside each other and work on a single task. One writes the code (driver) and the other reviews the code written (observer) and they switch their role frequently e.g. every 40 min.
Observer's main responsibilities are:
- Strategic direction of the overall code e.g. patterns, design quality, how methods fit into the class
- Come up with improvement ideas such as refactoring
- Continually observe the work of the driver and identify tactical defects such as syntactic, spelling, etc.
- Create the implemenation; focus on completing the tasks technically such as writing a method
- Use the Observer's comments as a safety guide
- Respect and listen to each other; empower and encourage each other.
- If necessary, organize 1-2 meetings to discuss how they can work together and based on what principles
- Participate in brainstorming
- Refactor the codes frequently e.g. 15 minutes in every 1 hour of development
- Prefer simplicity; avoid complexity or break it up. "Do The Simplest Thing That Could Possibly Work"
- Avoid waste
- 2 programmers sit beside each other and explain why they do want to do pair programming and its benefits.
- Explain or review the responsibilities of each role (observer and coder)
- Obviously the first 2 steps are not required each time!
- Pick up a task which has a high priority
- Quickly both roles explain and clarify the task and problem. What is the problem? Why we want to resolve it? What is the root? Where has it happened?
- Quickly both roles come up with ideas how to resolve the problem. Brainstorming. Agree on the overall strategy in up to one page.
- Make sure that you write the overall strategy on a paper or on notepad. Don't start coding without strategy!
- The Coder starts coding and the Observer starts observing and both consider their responsibilities as explained.
- Rotate your roles every, say, 40 minutes
- When the task is done, be happy, enjoy the work and go back to step 4
1) Better Design and Quality
Since 2 programmers think together design becomes better, simpler and more maintainable in comparison with solo programming.
2) Fewer Bugs and Reduced Development Costs
3) Learning and Training
Knowledge is shared and passed between the programmers.
4) Reduced Management Risks
If one programmer leaves the team, there is less risk to management.
5) Improved Focus, Concentration, Discipline and Efficiency
Every one can easily loose focus, check personal emails, surfing the web, etc. With Pair Programming the focus is much better acheived, time wasting is reduced and as a result efficiency will be improved.
6) Difficult Tasks Can be Solved Easier and Quicker
Because 2 minds work obviously.
7) Developers Become More Socially Adjusted Creatures!
Yes, they have to come out of their comfort zone and think loudly!
Challenges?
1) Work preference
Some developers are not interested in working in pairs.
Solutions:
- The benefits of pair programming should be discussed between the pairs
- Pairs should come up with ideas how they can work together.
- Gradually increasing the time of pair programming if it's felt that it works; otherwise changing the strategy or changing the pair
A less experienced developer may feel intimidated when working with a more experienced developer.
Solutions:
- Experts might be better to be paired with experts and less-experienced with less-experienced; however
- Quickly write the overall strategy of what the task is, how it should be implemented should be discussed, agreed and written before coding the task.
An experienced developer may find it tedious to tutor a less experienced one.
Solutions:
- Individuals might be better to be paired with ones from their own level.
- At the beginning Pair Programming may take time but as you learn how to do it, the performance will be increased as well.
Developers at times may feel uncomfortable developing with a pair. The coding styles and habits are often different.
Solutions:
- Use Company guidelines, standard and conding conventions; suggest improvement. Feel free to justify why you think what you think but at the same time be humble enough to accept a better idea if available.
- Less egos
Some managers think the development costs are increased.
Solution:
- Studies and tests have shown that the development costs are decreased and efficiency and productivity is improved from 15%-55%.
- Avoid Pair Programming for very simple tasks; now we should define what "very simple" mean?
No comments:
Post a Comment