CSC/ECE 517 Fall 2012/ch2a 2w9 ms: Difference between revisions
No edit summary |
|||
Line 46: | Line 46: | ||
* Prepare together for the coding you are going to do so that no misconceptions will be developed during the coding time. | * Prepare together for the coding you are going to do so that no misconceptions will be developed during the coding time. | ||
* Start with a reasonably well-defined task before you sit down. The task should be something you are confident that you can complete in an | * Start with a reasonably well-defined task before you sit down. The task should be something you are confident that you can complete in an hour or two | ||
hour or two | |||
* Agree on a solution: Decide on a general strategy to tackle the task that you decided upon. You may find it helpful to outline what you plan to do before you begin to code. | * Agree on a solution: Decide on a general strategy to tackle the task that you decided upon. You may find it helpful to outline what you plan to do before you begin to code. |
Revision as of 19:27, 24 October 2012
Pair Programming
This chapter will explain basic concepts of pair programming which is one of the popular Agile Software Development technique. We would also explain its benefits, advantages and disadvantages of pair programming. In the end we will conclude the topic by mentioning ongoing research in this field.
Introduction
Pair programming is a style of programming in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code or test. Use of this practice has been demonstrated to improve productivity and quality of software products in one of the paper <ref name = ref-paper />.
In Pair programming practice, two software engineers work on one task at one computer. One of the engineer acts as a driver who has control of the keyboard and mouse and (s)he creates the implementation. The other engineer acts as a navigator (also called as an observer) and watches and reviews the driver's implementation to identify defects and participates in on-demand brainstorming. The roles of driver and navigator are periodically rotated between the two software engineers. The observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his/her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
Extreme Programming (XP), is an emerging software development methodology. Pair programming is one of the corollary practices of Extreme Programming. XP attributes great success to the use of “pair programming". XP advocates pair programming with such fervor that even prototyping done solo is scrapped and re-written with a partner.
Principles of Pair Programming
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
In pair programming, two programmers are required to produce one piece of software (design, algorithm, code etc.) within a specified time limit. The two programmers are working with one mind responsible for every aspect of this piece of software. Both the driver and a navigator are equal participants in the process and both of the partners own everything and hence they should not blame each other for any defect in the artifact.
Play fair
With pair programming, one person has control of the keyboard or is recording design ideas, while the other is continuously reviewing the work. Even when one programmer is significantly more experienced than the other, it is important to take turns “driving,” so that the observer does not become disjoint or feel unimportant.
Don't hit your partner
Make sure your partner stays focused and on-task. The driver is awaiting continuous contribution and input from the navigator and hence both the partners should be focused on their part of work.
Clean up your mess
Pair programming makes many obvious unnoticed defects go away noticed by another person watching over the shoulders. Additionally, these defects can be removed without the natural animosity that might develop in a formal inspection meeting.
Don't take things too seriously
Pair programming demands ego-less programming approach from both the partners. It is essential for effective programming effort. Excess ego can manifest itself in two ways, both damaging the collaborative relationship. Attitude problems can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.
Take a break from working together every afternoon
It is acceptable to to work alone 10-50% of the time. Many programmers prefer to do experimental prototyping and logical thinking alone. Simple, well defined coding is more efficiently done by a solitary programmer and then reviewed with a partner.
Be aware of the power of two brains
Human beings can remember only to a certain extent and hence one must consult others to increase their knowledge. When two people are working together, each one has their own set of skills and expertise, which should be properly used while producing a piece of software. The unique skills of each individual will allow them to engage in interactions which pool their resources to accomplish their tasks.
How to achieve Pair Programming
There are some ways to achieve pair programming for an effective development process <ref name = ways-pair-prg />.
- Prepare together for the coding you are going to do so that no misconceptions will be developed during the coding time.
- Start with a reasonably well-defined task before you sit down. The task should be something you are confident that you can complete in an hour or two
- Agree on a solution: Decide on a general strategy to tackle the task that you decided upon. You may find it helpful to outline what you plan to do before you begin to code.
- Agree on one tiny goal at a time: something you can complete within a few minutes. Stating the problem in words to another person helps focus your mind and helps engage your partner's mind. It also ensures that you both know what you are working on right now.
- Rely on your partner, support your partner. When you're the driver, complete the current tiny goal as quickly as you can, ignoring larger issues. When you're the observer, read the code that the driver is writing as he or she writes it. Your job is code review. You should pay total attention, aiming to let nothing get by you. Think about possible bugs, larger issues, and ways to simplify or improve the design.
- Talk a lot! Say what you are about to do, ask for an implementation idea, ask for a better way to solve the problem at hand, bring up alternative ideas, point out possible inputs that the code doesn't cover, suggest clearer names for variables and subroutines, suggest ways to implement the code in smaller steps, tell the driver that little bit of API knowledge that they need right at the moment they need it, etc. Listen a lot, too, of course. When people are pairing well, they are talking back and forth almost non-stop.
- Sync up frequently. As you are working together, you will find yourself getting out of sync: becoming unsure what your partner is doing, or becoming unclear about the current task. This is normal. When it happens, sync up again. The key to good pairing is to sync up very frequently— within seconds or a minute of noticing that you're out of sync
- Take a moment to celebrate as you complete tasks and overcome problems.
- Switch roles often—at least every half hour. This keeps both the participants fully engaged, and both are in tune with the low-level details and the big picture.
Pair Programming Benefits/Advantages
Pair Programming Disadvantages
Ongoing Research
Conclusion
References
<references> <ref name = ref-paper> http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf </ref> <ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref> </references>