Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:51:11Z

Mjoseph:

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''" 
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition<ref name=quote/>

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

Pair programming is one of the corollary practices of Extreme Programming. [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)], is an emerging software development methodology. 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name=quote>[http://en.wikipedia.org/wiki/Gerald_Weinberg Gerald Weinberg]</ref>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:50:15Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''" 
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

Pair programming is one of the corollary practices of Extreme Programming. [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)], is an emerging software development methodology. 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name=quote>[http://en.wikipedia.org/wiki/Gerald_Weinberg Gerald Weinberg]</ref>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:47:47Z

Mjoseph:

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''" 
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:47:11Z

Mjoseph:

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''"
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:46:43Z

Mjoseph:

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''"
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:45:28Z

Mjoseph: /* Pair Programming */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their''
''own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''"
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

=Pair Programming=
This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:44:39Z

Mjoseph: /* Pair Programming */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=Pair Programming=
"''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their
own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant.''"
-G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-31T18:41:55Z

Mjoseph: /* Pair Programming */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=Pair Programming=
"'''The human eye has an almost infinite capacity for not seeing what it does not want to see.... Programmers, if left to their own devices, will ignore the most glaring errors in their output—errors that anyone else can see in an instant.''''"
- G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

This chapter will explain basic concepts of pair programming which is one of the popular [http://en.wikipedia.org/wiki/Agile_software_development Agile Software Development] technique. We would also explain its benefits, advantages and disadvantages. In the end we will conclude the topic by mentioning ongoing research in this field.

__TOC__

== 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.<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 writes the code for an 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.

[http://en.wikipedia.org/wiki/Extreme_programming 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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 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 because of 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 ====
It is acceptable 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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* Both programmers should be knowledgeable.

[[#top|Back to top]]

== 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 of 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, [http://en.wikipedia.org/wiki/Analysis_of_variance analysis of variance (ANOVA)] was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other [http://www.cs.utexas.edu/users/downing/papers/Agile2007.pdf Agile development methodologies]. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

Overall, there is considerable research going on in the field of pair programming and most of which is in academia.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:08:36Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler. All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:08:11Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler, All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan. Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:07:42Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler, All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>[http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course]</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan, Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:07:00Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> [http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf Laurie A. Williams, Robert R. Kessler, All I Really Need to Know about Pair Programming I Learned In Kindergarten] </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>[http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf Andrew Begel, Nachiappan Nagappan, Pair Programming: What’s in it for Me?]</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:05:33Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> Laurie A. Williams, Robert R. Kessler, All I Really Need to Know about Pair Programming I Learned In Kindergarten, http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name =ref-pp-academia-ucsc>Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms href="http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf"> Andrew Begel, Nachiappan Nagappan, Pair Programming: What’s in it for Me?</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-27T00:04:03Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== Partner picking principles ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.25]]

* Partners should have complementary skills.

* Partners should be of similar skill level.

* Both the partners should be flexible and open to new ideas.

* Both partners should have good communication skills.

* Partners should have compatible schedule.

* knowledgeable

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== References ==
<references>
<ref name = ref-paper> Laurie A. Williams, Robert R. Kessler, All I Really Need to Know about Pair Programming I Learned In Kindergarten, http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgramming.pdf </ref>
<ref name = ways-pair-prg> http://www.wikihow.com/Pair-Program </ref>
<ref name = ref-pp-academia-ucsc>Charlie McDowell, Heather Bullock, Julian Fernald, Linda Werner. The Effects of Pair-Programming on Performance in an Introductory Programming Course http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms> Andrew Begel, Nachiappan Nagappan, Pair Programming: What’s in it for Me? http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T23:33:31Z

Mjoseph: /* Conclusion */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== How to achieve Pair Programming ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.5]]

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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major perceived benefits of pair programming are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenarios> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T23:30:41Z

Mjoseph: /* Conclusion */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem <ref name = principle-pair />.
==== Share everything ====
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.

[[#top|Back to top]]

== How to achieve Pair Programming ==

[[File:pair-prg-partner.png|thumb|Pair programming|upright=1.5]]

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.

[[#top|Back to top]]

== When to use Pair Programming ==
Pair programming can be beneficial in certain scenarios. Some of them are mentioned here <ref name = benefit-scenarios />.

* Pair programming is very appropriate when a new team member is introduced into a group as a form of training.

* It may also be useful in complex re-factoring exercises, where one programmer thinks and the other does the coding.

* It may be used when programming efforts require significant object oriented designs, or development work on algorithms or procedures that have performance considerations.

== Pair Programming Benefits/Advantages ==

* Better communication skills are developed among the individuals.

* Better quality software is developed because of improved knowledge exchange and different perspectives from different people.

* The cycle time of software development is improved.

* Programmers are more satisfied in case of pair programming.

* Pair rotation makes staff training easier and reduces product risk. It enhances team building.

[[#top|Back to top]]

== Pair Programming Disadvantages ==

* The development progress can get hampered due to conflicts between the programmers and debate breakout among the group.

* Everyone has their own ideas and sometimes it becomes difficult to collaborate different ideas.

* It is possible that only one programmer does more than half of the work in the project.

[[#top|Back to top]]

== Research ==

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

[[#top|Back to top]]

== Conclusion ==

Pair programming is an agile programming practice which is gaining popularity in both academia and industry. Considerable research is also going on in this area. Major benefits of pair programming found are increased quality of code, fewer bugs, better awareness of code among team members etc. It still has problems like lesser productivity, conflicts among partners etc. Many of these problems could be solved by proper selection of team members and applying pair programming to appropriate type of projects. This a useful software engineering practice which teams should consider to increase the quality of their software products.

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
<ref name = principle-pair> http://anh.cs.luc.edu/170/Kindergarten.html </ref>
<ref name = benefit-scenario> http://ctotodevelopers.blogspot.com/2008/04/when-to-use-pair-programming.html </ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:48:17Z

Mjoseph: /* Research */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?" <ref name = ref-pp-industry-ms/>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:47:29Z

Mjoseph: /* Industry */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?". Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:47:00Z

Mjoseph: /* Industry */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?"<ref name = ref-pp-industry-ms>. Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:46:43Z

Mjoseph: /* References */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?". Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
<ref name = ref-pp-industry-ms>http://research.microsoft.com/en-us/um/people/abegel/papers/esem-begel-2008.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:45:57Z

Mjoseph: /* Industry */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done by Andrew Begel and Nachiappan Nagappan on Pair Programming at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?". Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:42:39Z

Mjoseph: /* Industry */

[[File:Pair programming 1.jpg|thumb|Pair programming|upright=1.5]]

=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.

__TOC__

== 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.

[[#top|Back to top]]

== Principles of Pair Programming ==
There are some principles of pair programming in the context of Fulghum's Poem. (Give a link here? )
==== Share everything ====
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.

[[#top|Back to top]]

== 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.

[[#top|Back to top]]

== Pair Programming Benefits/Advantages ==

[[#top|Back to top]]

== Pair Programming Disadvantages ==

[[#top|Back to top]]

== Research ==

[[#top|Back to top]]

===Academia===
A group of researchers from the University of California, Santa Cruz did a study of "The Effects of Pair-Programming on Performance in an Introductory Programming Course" <ref name = ref-pp-academia-ucsc/>. Computer programming was essentially taught and practiced as a solitary activity. But, they wanted to see if the upcoming trend of Xtreme programming (XP) and especially Pair Programming could help in learning programming.

For this purpose during the 2000-2001 academic year, data was gathered from students enrolled in two sections of an introductory programming course at the University of California – Santa Cruz. These courses were designed for Computer Science, Management and other Engineering majors. One of the two sections required students to complete programming assignments in pairs (N=172), while the other required students to write programs independently(N=141). The programming assignments, lectures, and quizzes were comparable, and the final exam was identical in both sections. The analysis of the data gathered lead to some interesting finds. These are summarized below.

To compare whether programming scores differed as a function of pair-programming experience, analysis of variance (ANOVA) was conducted. Among all students who completed the course, students in the pairing class scored significantly higher on the programming
assignments (M=86%) than those in the non-pairing class (M=67%). Overall, the scores from the entire pair-programming section (M=86%) were significantly higher than the even scores of the top half of the non-pairing class (M=77%). So we can reject the theory that the scores for the pair programming group merely reflects the work of the brighter student in the group. The mean exam score in the non-pairing class (M= 75%) was slightly higher than the mean exam score in the pairing class (M=73%). This small difference, however, was not statistically significant. Another major statistic was that the percentage of students who finished the final was dramatically higher in the pairing section (92% vs. 76%). So pairing increased the likelihood that students complete introductory programming class.

So according to the study, it appears plausible that as a result of pair-programming, students that might otherwise have dropped the course, completed the course. Also, it also appears that the programs of even the better students benefited from pair-programming. The data also suggested that students who work in pairs produce better programs. Furthermore, they perform comparably on exams (when not adjusted for varying attrition rates), and possibly significantly better on a final exam, to students required to program individually.

===Industry===

Research done Andrew Begel and Nachiappan Nagappan at Microsoft by was published in the paper entitled "Pair Programming: What's in it for Me?". Their main focus was to understand how pair programming methodologies are used, what kinds of problems and benefits they are perceived to have, the types of partners people would like to work, and a general consensus on PP's usefulness in the software engineering professional community. They did this by asking a sample of developers at Microsoft directly about their current development practices.

Their findings were interesting. They found that 22% of the participants had practiced pair programming, but only 3.5% did it in their current project. Most practitioners are more experienced than the average Microsoft employee practicing other Agile development methodologies. Around two-thirds like pair programming and believe it is a workable practice, but less than half would agree to that of their team's use of pair programming. Three-eighths of the respondents believe that pair programming takes more time than programming alone, but two-thirds believe that the quality of the resulting software is better.

Also part of the survey was trying to rank the perceived benefits and problems of pair programming. The top benefit reported was fewer bugs in the source code and spotting of bugs earlier. The second most cited benefit indicated that pair programming helps to spread code understanding between the members of the pair. So, "There is never only one person in the team who knows all the code." In third place was higher quality code. Fourth was the ability to learn from a partner. The use of pair programming is a good way to “quickly ramp-up new members.” The fifth benefit was the perception that software being built had a “better architecture and implementation” mainly due to “adherence to good design and standards.”

The participants noted few problems with pair programming too. The number one problem reported with pair programming was cost. Two people are being paid to the do the work of one. The second problem is scheduling time to work in pairs. Two partners require equivalent schedules and suffered double scheduling conflicts. The third most cited problem is a clash of personalities. Finding compatible partners is a difficult process according to many. The fourth problem was trouble resolving disagreements and the fifth problem was that engineers were worried that they will be paired with a partner who is not as smart or skilled as they are.

The study also published a list of qualities that programmers desired in their partners ordered according to preference. The top attribute of a good pair programming partner is that the person has complementary skills to your own. The sentiment in most responses was that my partner “usually looks at things from a different angle.” and he has a “different background which provides a different perspective.” The second attribute is flexibility. An ideal partner is “open minded,” and “open to new ideas.” The third attribute that people looked for was communication skills. Every study of pair programming has shown that it is a communications-intensive process. Tied for fourth is that the person is smart and personable.

This study presented an interesting view of the programmers from the industry.

== Conclusion ==

[[#top|Back to top]]

== 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>
<ref name = ref-pp-academia-ucsc>http://users.soe.ucsc.edu/~charlie/pubs/sigcse2002.pdf</ref>
</references>

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-26T05:22:42Z

Mjoseph: /* Research */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:55:13Z

Mjoseph: /* References */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:54:56Z

Mjoseph: /* Academia */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:53:34Z

Mjoseph: /* References */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:53:15Z

Mjoseph: /* References */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:51:28Z

Mjoseph: /* Academia */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:47:10Z

Mjoseph: /* Ongoing Research */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:46:43Z

Mjoseph: /* Academia */

CSC/ECE 517 Fall 2012/ch2a 2w9 ms

2012-10-25T05:36:53Z

Mjoseph: /* Ongoing Research */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-15T00:05:05Z

Mjoseph: /* Why do we need AOP? The banking example */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance 
def balance=(amount)
@balance = amount
persist_balance
end 
def initialize
@balance = retrieve_balance
end 
def deposit(amount)
@balance += amount
persist_balance
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance
end 
def retrieve_balance
# Get from database
end 
def persist_balance
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==AOP in Ruby==
Ruby does not have native AOP support. But Ruby's metaprogramming features cover many of the aspect requirements. 'method_missing' and reflection in Ruby are classis examples of that. 'method_missing' allows the code to inspect the method call at runtime and redirect to some default method or define a new method if the called method does not exists. Similarly Ruby provides naive support to implement pointcuts and wrapper methods. They are discussed below.

===Pointcut equivalent in Ruby===
There are no pointcuts in Ruby. But they can be simulated by the inspect method that Ruby provides.

# List all the classes
ObjectSpace.each_object(Class) do |o|
puts o.inspect
end 
# List all the modules
ObjectSpace.each_object(Module) do |o|
puts o.inspect
end 
# List all the instances of class String
ObjectSpace.each_object(String) do |o|
puts o.inspect
end

===Adding advice in Ruby===
In Ruby, alias can be used to wrap methods with advice.

foo.rb
class Foo
def bar
"bar"
end
end 
foo_advice.rb
class Foo
alias old_bar bar
def bar
"{[< "+ old_bar+ " >]}”
end
end

In the above code, the alias will be executed eveytime a call to method 'bar' is made. The output of the above code will be as follows:

puts Foo.new.bar
=> "{[< bar >]}"

==AspectR==
We saw how AOP can be implemented in Ruby without any extra support in the above sections. AspectR is free library which provides API's to the same for Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. The code for AspectR can be downloaded from [http://prdownloads.sf.net/aspectr/aspectr-0-3-5.tar.gz here]. AspectR was originally called advice.rb and written by Avi Bryant. Later Robert Feldt changed/tweaked/extended it.

===Main features of AspectR===
*Joinpoints: Ruby does not have the notion of Jointpoints. But it can be considered as method or constructor calls or even exception handlers.
*Advices: It contains before (pre) advice, after returning and after throwing (post) advice, which indicates what is to be done before/after the jointpoint is called.
*Aspects: They are the classes that inherit from Aspect. It supports "abstract" Aspects and overriding between advices.
*Wildcards: RegExp can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to.
*Pointcut parameters advices can access: object and method receiving call, arguments to call, return values, and exceptions raised.

===AspectR Syntax===
Advice methods are passed a variable number of parameters:
*the first is the name of the method currently being wrapped
*the second is the object receiving the method call
*the third is the exit/return status:
**Array with return value(s) if the method exited normally
**true if the method exited with an exception
**nil if the method hasn't yet exited (for preAdvice)
*the rest are the arguments that were passed to the wrapped method.

Here is the sample syntax:
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end 
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...)
or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/)
or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)
===Banking account example in AspectR===

class BankAccount
attr_reader :balance
def balance=(amount)
@balance = amount
persist_balance
end 
def initialize
@balance = retrieve_balance
end 
def deposit(amount)
@balance += amount
persist_balance
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance
end
end 
class Persist < Aspect
def retrieve_balance
# Get from database
end
def persist_balance
# Save to database
end
end 
Persist.new.wrap(BankingAccount, :retrive_balance, :persist_balance, /withdraw/)

==How AspectR is different from AspectJ==
*Join points: Join points are not defined separately in AspectR as they are in AspectJ. Instead the method and constructor calls acts as join points.
*Most of the point cut designator primitives that are present in AspectR differ from AspectR.
*There is a huge difference in composition of pointcut designators. But you can of course specify several method calls in different classes and objects in a point cut.
*Around advices are more easy to add in AspectR than AspectJ but mostly before and after advices are used.
*AspectR has control-flow based crosscutting.

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University
# [[AspectJ|AspectJ - wikipedia]]
# [http://aspectr.sourceforge.net/ AspectR - Simple aspect-oriented programming in Ruby]
# [http://www.ruby-doc.org/gems/docs/a/aspectr-0.3.7/AspectR.html AspectR - Ruby documentation]
# Aspect-Oriented Programming in Ruby by Dean Wampler

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-14T23:38:31Z

Mjoseph: /* AOP in Ruby */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==AOP in Ruby==
Ruby does not have native AOP support. But Ruby's metaprogramming features cover many of the aspect requirements. 'method_missing' and reflection in Ruby are classis examples of that. 'method_missing' allows the code to inspect the method call at runtime and redirect to some default method or define a new method if the called method does not exists. Similarly Ruby provides naive support to implement pointcuts and wrapper methods. They are discussed below.

===Pointcut equivalent in Ruby===
There are no pointcuts in Ruby. But they can be simulated by the inspect method that Ruby provides.

# List all the classes
ObjectSpace.each_object(Class) do |o|
puts o.inspect
end 
# List all the modules
ObjectSpace.each_object(Module) do |o|
puts o.inspect
end 
# List all the instances of class String
ObjectSpace.each_object(String) do |o|
puts o.inspect
end

===Adding advice in Ruby===
In Ruby, alias can be used to wrap methods with advice.

foo.rb
class Foo
def bar
"bar"
end
end 
foo_advice.rb
class Foo
alias old_bar bar
def bar
"{[< "+ old_bar+ " >]}”
end
end

In the above code, the alias will be executed eveytime a call to method 'bar' is made. The output of the above code will be as follows:

puts Foo.new.bar
=> "{[< bar >]}"

==AspectR==
We saw how AOP can be implemented in Ruby without any extra support in the above sections. AspectR is free library which provides API's to the same for Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. The code for AspectR can be downloaded from [http://prdownloads.sf.net/aspectr/aspectr-0-3-5.tar.gz here]. AspectR was originally called advice.rb and written by Avi Bryant. Later Robert Feldt changed/tweaked/extended it.

===Main features of AspectR===
*Joinpoints: Ruby does not have the notion of Jointpoints. But it can be considered as method or constructor calls or even exception handlers.
*Advices: It contains before (pre) advice, after returning and after throwing (post) advice, which indicates what is to be done before/after the jointpoint is called.
*Aspects: They are the classes that inherit from Aspect. It supports "abstract" Aspects and overriding between advices.
*Wildcards: RegExp can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to.
*Pointcut parameters advices can access: object and method receiving call, arguments to call, return values, and exceptions raised.

===AspectR Syntax===
Advice methods are passed a variable number of parameters:
*the first is the name of the method currently being wrapped
*the second is the object receiving the method call
*the third is the exit/return status:
**Array with return value(s) if the method exited normally
**true if the method exited with an exception
**nil if the method hasn't yet exited (for preAdvice)
*the rest are the arguments that were passed to the wrapped method.

Here is the sample syntax:
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...)
or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/)
or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University
# [[AspectJ|AspectJ - wikipedia]]
# [http://aspectr.sourceforge.net/ AspectR - Simple aspect-oriented programming in Ruby]
# [http://www.ruby-doc.org/gems/docs/a/aspectr-0.3.7/AspectR.html AspectR - Ruby documentation]
# Aspect-Oriented Programming in Ruby by Dean Wampler

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-14T22:09:10Z

Mjoseph: /* References */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University
# [[AspectJ|AspectJ - wikipedia]]
# [http://aspectr.sourceforge.net/ AspectR - Simple aspect-oriented programming in Ruby]
# [http://www.ruby-doc.org/gems/docs/a/aspectr-0.3.7/AspectR.html AspectR - Ruby documentation]
# Aspect-Oriented Programming in Ruby by Dean Wampler

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-14T22:08:13Z

Mjoseph: /* References */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University
# [[AspectJ|AspectJ - wikipedia]]
# [http://aspectr.sourceforge.net/ AspectR - Simple aspect-oriented programming in Ruby]
# [http://www.ruby-doc.org/gems/docs/a/aspectr-0.3.7/AspectR.html AspectR - Ruby documentation]

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-14T21:57:43Z

Mjoseph: /* References */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-14T21:50:36Z

Mjoseph: /* Aspect Oriented Programming (AOP): AspectJ and AspectR */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==References==

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T20:43:27Z

Mjoseph: /* Banking example in Java using AOP */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T20:38:57Z

Mjoseph: /* Banking example in Java using AOP */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T20:33:48Z

Mjoseph: /* Banking example in Java using AOP */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T20:32:31Z

Mjoseph: /* AspectJ: AOP in Java */

CSC/ECE 517 Fall 2012

2012-09-13T05:04:37Z

Mjoseph:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T02:47:01Z

Mjoseph: /* Pointcuts */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T02:43:10Z

Mjoseph: /* Pointcuts */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T02:36:59Z

Mjoseph: /* Aspect Oriented Programming (AOP) */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T02:35:49Z

Mjoseph: /* AspectJ: AOP in Java */

=Aspect Oriented Programming (AOP)=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T01:45:35Z

Mjoseph: /* Lanugage description */

=Aspect Oriented Programming (AOP)=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T01:33:27Z

Mjoseph: /* AspectJ: AOP in Java */

=Aspect Oriented Programming (AOP)=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance # 1 
def balance=(amount)
@balance = amount
persist_balance # 2
end 
def initialize
@balance = retrieve_balance # 3
end 
def deposit(amount)
@balance += amount
persist_balance # 2
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance # 2
end 
def retrieve_balance # 3
# Get from database
end 
def persist_balance # 2
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. Here, the advice refreshes the display every time something on Point is set, using the pointcut declared above:

after () : set() {
Display.update();
}

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance).

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T01:15:31Z

Mjoseph: /* History and contributors= */

CSC/ECE 517 Fall 2012/ch1 1w27 ms

2012-09-13T01:15:02Z

Mjoseph: /* AspectJ: AOP in Java */