Adopting XP Practices for Teaching Object Oriented Programming Karen Keefe(1), Judithe Sheard(2), Martin Dick(3) Faculty of Information Technology(1),(2) Monash University 900 Dandenong Road, Caulfield East 3156, Victoria School of Business Information Technology(3) Royal Melbourne Institute of Technology GPO Box 2476V Melbourne 3001, Victoria
[email protected](1)
[email protected](2)
[email protected](3)
Abstract This paper reports on an Action Research project that investigated the effect of introducing a number of Extreme Programming (XP) practices as teaching techniques to introductory programming students. The focus of the study was on using the XP practices to assist students in an introductory programming subject develop object oriented programming skills, problem solving skills and teach them to become more self-sufficient in their learning. The research is concerned with applying several of the XP practices as a means of value-adding to current pedagogical approaches. The results from this first exploratory cycle have been mixed, but there have been enough positive results to feed forward into the next action research cycle.• Keywords: Learning to program, Extreme Programming, pair programming, simple design, refactoring, test driven development, Action Research
1
Introduction
•
implementing abstract programming techniques in different situations; and
•
understanding and employing object oriented programming concepts such as inheritance, abstract and concrete classes and interfaces.
A review of the literature has shown these are difficulties common to many introductory programming students (Carbone, Hurst, Mitchell, & Gunstone, 2001; McCracken et al., 2001; Thomas, Ratcliffe, & Robertson, 2003). A number of different approaches to teaching programming have been adopted in an attempt to address these issues. More recently practices taken from agile software development methodologies have been trialled in different computing courses. A number of research studies have reported on different practices of the Extreme Programming (XP) methodology in this context. Results reported from these studies have shown varying results, with some practices being more successful than others.
Many students find learning how to program a difficult task, and there are various obstacles that get in their way as they start down the path of learning software development (Soloway, 1986; Thomas, Ratcliffe, Woodbury, & Jarman, 2002). In her teaching practice the researcher has found that students in introductory programming subjects experience the following difficulties:
The research reported in this paper investigated the issues related to implementing XP practices in introductory programming as a means of value-adding to current pedagogical approaches. The particular focus of the research was on the benefits that could be gained by the students by using these practices such as the learning of real-world skills which they can transfer to other areas of their studies and to future employment.
•
developing a strategy for breaking a problem down into its components;
•
understanding the mechanics of programming, for example: parameter passing, assigning values returned from methods and declaring variables;
The research reported in this paper is not an investigation into teaching students the XP software development methodology, but rather one of using selected XP practices to enhance the learning experience of introductory programming students.
2
Copyright © 2006, Australian Computer Society, Inc. This paper appeared at the Eighth Australasian Computing Education Conference (ACE2006), Hobart, Tasmania, Australia, January 2006. Conferences in Research in Practice in Information Technology, Vol. 52. Denise Tolhurst and Samuel Mann Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included.
Use of XP in Tertiary Teaching
XP is an agile software development methodology that was developed eight years ago. The first XP project was completed in 1997 for the Chrysler corporation (Beck, 1999). XP, along with other agile methodologies, has become a widely used and accepted practice in industry. The inventors of XP, Kent Beck and Ward Cunningham, developed the methodology as a highly disciplined approach to software development, with an emphasis on
the people and product (Beck & Andres, 2004; Neill, 2003). XP consists of twelve core practices and four underpinning values, which, combined, foster a learning and communicative environment within the development team (Hedin, Bendix, & Magnusson, 2003). The remaining parts of this section describe the four core practices used in this study, why they were chosen and why the other eight practices were not chosen. XP practices were first introduced into tertiary learning environments in 1999 (Williams, 1999). Since that time XP has been taught as a software development methodology in classrooms and on capstone projects (Holcombe, Gheorghe, & Macias, 2001; Keefe & Dick, 2004; Noble, Marshall, Marshall, & Biddle, 2004) and some of the individual practices have been adopted as tools to teach programming at various levels (Edwards, 2003; George & Williams, 2003; Williams, 2000). The remainder of this section describes four of the twelve core practices chosen for adoption in this study and discusses the reasons for their selection.
2.1
Pair Programming
Pair programming is a collaborative practice of two programmers working side-by-side on one machine to complete a task. Both developers are engaged in the process of coding, one designated as the ‘driver’ and the other as the ‘navigator’ (Bevan, Werner, & McDowell, 2002). The driver concentrates on the task at hand, while the navigator constantly reviews the code, and is thinking ahead, watching for upcoming problems. The XP methodology insists that all production code, code that is incorporated into the software released to the customer, is written by two developers (Wake, 2001). The earliest study found which reported on the use collaborative programming was 1993 (Wilson, Hoskins, & Nosek, 1993). Their study suggested that novice programming students benefited from collaborative work when developing strategies for solving programming problems. A leading researcher in the use of pair programming in programming courses is Williams (Katira et al., 2004; Shukla & Williams, 2002; Williams, 2000). Her major work of 2000 demonstrated that pair programming could be positively incorporated into programming courses at different levels. Recent research studies found that students adopting pair programming can improve their problem solving skills and improve the quality of code they produce. Students who are pair programming are encouraged to learn from each other. Furthermore, programmers who work collaboratively report that they enjoy the experience more (Williams, 2000). Initially pair programming research focused on its practicality and methods of implementation in tertiary learning environments. More recent research has been centred on the make up of student pairs (Katira et al., 2004; Thomas, Ratcliffe, Woodbury, & Jarman, 2002). Researchers have been using different methods of personality type testing to categorise student
personalities, in order to uncover which combinations of personality types work best. Perception of student skill level, actual skill level and personality type seem to play a part in the success of the pairing students (Nosek, 1998).
2.2
Test Driven Development
Test driven development (TDD) is a key practice in XP. It is the process of writing test cases for code, before writing the code. The process is iterative, a developer will cycle back and forth between the test cases and their code with each change that is made. This is often described as the rhythm of TDD. The design of the system is driven by the test cases as they are written (George & Williams, 2003). It is argued that TDD reduces coupling between classes and it produces more cohesive classes. These are two key issues with object oriented design and programming (Beck, 2001). Few studies were found of using TDD in programming courses. The research that has been performed presents mixed results. Edwards (2003) had positive results from the introduction of TDD to his students. These included the promotion of an incremental development style; earlier detection of errors; and stopping “big bang” approaches to code integration. Muller and Hagner (2002) found that TDD had a positive effect on the code their students developed. They produced marginally more reliable code, when compared to students who did not take a test first approach. Pancur, Ciglaric, Trampus and Vidmar (2003) found that their students had difficulties getting into the mindset of TDD, contrary to Edwards (2004), who found that students did not have trouble finding the rhythm of TDD.
2.3
Simple Design
The developers of XP define simple design as the technique of doing the simplest thing that will possibly work to get the job completed, while avoiding any unnecessary complexity (Astels, Miller, & Novak, 2002). Simplicity in design means that the code must run all the tests that have been written, there is no duplicate code and there are no unnecessary classes and methods (Beck, 1999). In the current literature, little has been documented specifically regarding simple design as a pedagogical approach to teaching programming at any level. One study, by Greca, Jovanovic and Harris (2003), documented the results of using a combination of practices when teaching programming, but the study did not specifically identify whether simple design was successful.
2.4
Refactoring
The use of refactoring goes hand-in-hand with simple design. The practice of refactoring is used to keep the design simple by removing those aspects in the code that stop it adhering to the simple design definition (Astels et al., 2002).
Refactoring was one of the practices included in the Greca study mention above. Similarly to simple design it was not mentioned whether refactoring as an individual practice was successful. A combination of several XP practices including refactoring and simple design was found to have a positive result on the overall grades of the student cohort.
2.5
Choice of Practices
The reports of the various studies indicated that XP practices may have benefits when used in introductory programming courses. In considering the use of XP in the introductory programming course it was decided to select only those practices relevant to introductory programming students rather than adopting the whole methodology. The purpose of introductory programming courses is to teach students how to program, and not to teach them the entire software development process. The complete set of twelve XP practices comprises a full software development lifecycle, which is beyond the scope of an introductory programming courses. The four practices, discussed in the previous sections, have been identified for use in this research because they focus on development of code, problem solving, design, code improvement and testing. It was felt that these particular practices could address the difficulties discussed earlier. Pair programming is a widely used practice and there are many research studies showing success in adopting this approach with programming students of all levels. Simple design and refactoring were chosen for the purpose of teaching object oriented concepts such as inheritance, polymorphism and code re-use. Testing is included in all programming modules taught in the diploma courses at this institution. The focus stays on testing for a short period of time, before switching to other topics and students rarely continue to practise this skill. An increased focus on testing could address the issues identified earlier. JUnit has been taught as the testing tool of choice in later semesters and students are expected to use it when completing capstone projects in fourth semester. These four were among the six XP practices Greca et al. (2003) identified as contributing to feedback and learning by students. In their study they investigated the use of pair programming, simple design, refactoring, TDD, coding standards and collective code ownership in teaching C++ to introductory programming students. These practices were chosen because of the suitability for small programming examples. The XP practices of on-site client, the planning game, system metaphor, 40-hour week, collective code ownership, small releases and continuous integration were omitted because they are not relevant in an introductory programming course. The on-site client, planning game, system metaphor and 40-hour week practices are not relevant in the teaching context. The majority of the programs that students write are too small to be anything other than a single release and continuous integration would not be practical with the size of their
programs. The students do not use any form of version control, such as CVS, so this also nullifies continuous integration in this setting. The remaining practice of implementing c o d i n g standards was not chosen primarily because this is a practice that has always been encouraged. Students are expected to adhere to general coding standards and their programming environment automatically formats the code to meet these standards.
3
Research Methodology
The overarching methodology implemented was Action Research. This is a systematic approach to research where the researcher collects data, analyses and interprets the data, and formulates a plan in which to affect positive change (Mills, 2000). The Action Research cycle was implemented on a weekly basis, allowing the researcher time to spend reflecting and implementing changes in the implementation of the XP practices. An important factor of any research conducted in an educational institution is the students’ welfare, and Action Research, allows for changes and improvements to take place throughout the course of the project. An interpretivist research approach was adopted because it allows insight into the students’ perceptions of the XP practices. Several data gathering techniques were employed during the course of the project. The advantage of using different data gathering techniques is in obtaining different perspectives on the data gathered. This technique, known as triangulation, allows for more reliable conclusions being drawn than from a single data source (Williamsons, Burstein, & McKemmish, 2002). The data reported for the case studies was gathered from a number of sources as follows: •
surveys conducted at the start and end of the semester;
•
students’ results for previous programming subjects;
•
reflective questions gathered by questionnaire; and
•
observations of the students by the researcher during the course of the semester.
Table 1 describes the different data gathering techniques used through the course of this research. Method Surveys
Description Three surveys were undertaken during the course of the semester. 1. A start of semester quiz tested the students’ understanding of concepts taught during the first semester programming subject. 2. A end of semester quiz tested the students’ understanding of concepts taught in the semester where the XP practices were introduced. 3. A survey seeking the students’ perceptions of the XP practices.
Student Results
Reflective Questions
Observations
Results from student assessments, assignments, exams and exercises. The results were gathered from the current semester and past semester, from the same student cohort and previous cohorts that have undertaken the subject. Self-reflection questions given to students during the semester. These focused on the students’ perceptions of the XP practices, problem areas and successful areas. Observations of the students’ implementation of practices made by the researcher during each two hour teaching session.
Table 1: Data gathering techniques used in this study
3.1
Research Context
The programming subject that was used in this research project is a second semester subject in the Diploma of Information Technology, Software Development or Website Development at Swinburne University of Technology – TAFE1. The language used in both first year programming subjects is Java 1.5, and the environment used is Netbeans 3.6. The subject is taught over a period of eighteen weeks, the assessment comprises two examinations, an assignment and various class exercises. The topics covered are: inheritance; interfaces; basic collection classes and arrays; graphical user interfaces; file input and output; and unit testing.
3.2
Profile of Student Cohort
The student cohort consisted of nineteen students – thirteen completed the prerequisite subject the previous semester, and six were repeating the subject. Of the thirteen students new to the subject, three achieved high distinctions; one a distinction; five achieved credits; and four passes in the prerequisite subject. The six repeating students failed their previous attempts with marks well below the fifty percent pass mark. The class was a mix of mature age students and those directly from secondary college. There were three women in the class, three international students and sixteen local students. Twelve students sat the final exam. Seven of the nineteen students dropped out of the subject before the end of the semester exam – two before the first exam and five withdrew from study all together. This was a higher than normal number of students withdrawing from second semester. Of the twelve students who sat the exam, five passed the subject; two achieved high distinctions, one a distinction, one a credit and one a pass. Only one of the
1
TAFE – Technical and Further Education colleges are tertiary education institutions that offer vocational courses. TAFE offers diploma level courses that can lead into degree courses at a university level.
repeating students passed the subject, but the other repeating students made significant improvements in their overall marks. These results for the students who passed are consistent with the results from previous semesters. TAFE traditionally caters to students who have not developed the academic background to progress straight from secondary college to university. TAFE also attracts students who are returning to study after a period of absence, or are seeking to change their career path. There are often pathways from TAFE diplomas into higher education.
3.3
Implementation of XP Practices
The following section discusses the implementation of the four XP practices. Pair Programming Pair programming was introduced in the first session of the semester. This initial session began with an explanation of pair programming, its noted benefits, and a discussion on the roles and responsibilities of programmers involved in the practice. The teacher assisted students with their pair programming techniques by reminding pairs to swap roles or by sitting with a pair and working directly with them. Students were put into pairs at the start of a session and the pairs were, in the main, chosen by the researcher. This choice varied due to fluctuations in student attendance patterns. Some sessions were designated as optional pairing sessions. In these sessions students decided if and with whom they paired. Unless there was an odd number of students in the class, all opted to pair during these optional sessions. Throughout the course of the semester, all students paired with every other student for at least one week. This is in keeping with the XP pair programming practice, which states that developers should regularly alter their partners. Test Driven Development Unit testing and the XP practice of test driven development were introduced to students at the start of the semester. Students were taught JUnit as a tool for writing unit tests at the beginning of the semester, at a stage when most students were still struggling with basic programming. Students were encouraged to develop their tests and devise test data as a method of developing algorithms to solve exercises set during each class. Simple Design Simple design was introduced along with the topics of interfaces and inheritance. The practice was used to demonstrate how to implement these concepts and why they are used. Refactoring Refactoring was introduced at the same time as simple design. Classes without inheritance were refactored to pull out common elements and create inheritance hierarchies to demonstrate object oriented design. The focus of this practice was on the more abstract concepts, illustrating the importance of program design,
demonstrating the concepts in a practical setting and their importance in object oriented programming. Practical examples were used to demonstrate simple design and refactoring. These examples were based on a simulator that eventually grew into the code for the assignment. Initially there was only one actor in the simulation, then gradually more actors were introduced and the code was refactored to create an inheritance hierarchy and incorporate the Observer interface and Observable Java class.
4
When pair programming Harry considered the most important factors were: compatibility with partner; similar programming skill; similar understanding of concepts; and similar levels of motivation. Harry said that when pair programming outside of class time he was: …lucky enough to work with someone who is of a similar work ethic and understanding level to myself.
Student Experiences with XP Practices
Following is a selection of the students’ experiences with the XP practices from this study. These experiences are presented as mini case studies and are drawn from surveys, self reflection questions and the researcher’s observations of students implementing the practices during class time. The students’ names have been changed for the purpose of anonymity.
4.1
would take a lot longer to test a class than a test class would. I used my test class before this. I knew what figures I was expecting in my main class and would often write multiple lines to make sure my code was working.
Harry
Harry’s overall grade for the first semester programming subject was a high distinction, demonstrating an above average grasp of the programming concepts and skills introduced in this subject. The start of semester quiz showed that at the start of the second semester he had retained these skills. Harry completed the end of semester quiz, except for a question asking for students to create a test case for a scenario. In response to questions about testing Harry said that implementing JUnit was one of his biggest achievements in the class. He also successfully answered the JUnit question on the mid-semester exam. Harry’s understanding of the concepts was excellent as was his implementation of the concepts. Harry preferred the practice of refactoring over the other three practices. Using refactoring was helpful when attempting to improve his code and the design of algorithms. Refactoring was also popular with the other students who excelled in the subject. [Refactoring] seeing code and checking for ways to improve it, that help me to be more efficient the next time I code. Harry did not feel that simple design helped him when learning interfaces, inheritance or polymorphism. Observations of Harry during the semester were that he struggled with these concepts, particularly interfaces. When implementing a test first approach, Harry initially steered away from using JUnit and simply wrote his own driver class to manually perform testing on his classes. He found that writing tests in JUnit was time consuming, compared to the way he was used to writing tests for his code, however he did follow the same principles for both. I only recently found out about using a setup method within JUnit to instantiate objects and call methods that each method would use throughout the JUnit test case. Prior to this I did not use JUnit out of class time as for me it
These factors were important to him, when looking for someone to pair with. During class time if paired with someone who was not of a perceived similar level to him, then he found the process a hindrance rather than being helpful. Overall Harry felt that the XP practices were not particularly helpful for him improving his programming skills or the understanding of the topics taught during the semester. Observations of Harry implementing the XP practices were that when pairing with someone of similar motivation pair programming was very successful. This was regardless of the partner’s programming ability. Harry’s partners also needed to be proactive in the pair programming process, and not simply observe or be directed in tasks. Harry was also very active in refactoring his code, and learning from the process.
4.2
Sam
At the end of the first semester Java subject, Sam had a solid understanding of the concepts that were taught. This was demonstrated by the start of semester quiz and in his academic results. At the end of the semester Sam achieved an above average result for the subject achieving a distinction for his final grade. Sam enjoyed the practices of pair programming, simple design and refactoring. He found them the most helpful and enjoyable of the practices. Sam stated that the important factors for successful pair programming were: compatibility with partner; similar programming abilities; similar understanding of concepts; and similar motivation levels. Although he enjoyed pair programming, he believed it was not always helpful: … in class sometime it does not [help], what if you are pair programming with a person who is very good, or have done this course before or who is very bad in Java. Sam was one of the few students who pair programmed out of the classroom, particularly when completing homework tasks that were set. Testing was the least successful of the XP practices for Sam, and he only completed test cases when prompted.
When Sam did use JUnit and completed tests for code he found that it was useful. When using JUnit I am able to work out the answer, and try to run the tester to see if the answer is correct. If not the tester [will] tell what and where the problem is. According to Sam, simple design did not help him in understanding the object oriented concepts of inheritance, polymorphism and interfaces, but did help him improve his programming in general. There was a similar response to use of the practice of refactoring. The process of working through the refactoring his code helped Sam understand what his program was supposed to be doing. It was observed that pair programming was a very useful technique for Sam, particularly when pairing with stronger students such as Harry or James, as they were able to extend him. Working with the weaker students Phillippa and Petra was also good for Sam as they enabled him to consolidate the concepts as he explained tasks and solutions to tasks. He did have a tendency to dominate the coding aspect, unless specifically told by the teacher to swap roles.
4.3
James
At the completion of his first semester programming subject, James showed an excellent understanding of the programming concepts taught. He achieved a high distinction in the prerequisite subject which he carried through into the second semester. James’ results at the start of semester quiz were very good, demonstrating he was very confident with concepts taught during the first semester. James also had previous experience in a programming language other than Java. His result on the end of semester quiz was excellent and it was clear that James understood the concepts taught throughout the semester. This was confirmed by James’ results on the exams and assignment work. For both exams James achieve excellent grades. James did not find that pair programming was helpful to him in understanding any of the concepts taught during the semester. Generally he did not use this practice outside of the classroom. James wrote in his reflection diary: I do not pair program outside of class because generally the pace I program at is faster than anyone I pair with can cope with. James indicated that an important factor to him when pair programming was compatibility with his partner. He also stated that a partner with a similar level of motivation to the subject was important, as was the case for many of the students. Similar programming abilities and understanding of concepts were also important. A partner of the same gender was the least important factor when pair programming. James found that test first was helpful, but only when he remembered to complete the testing process. About JUnit and the testing process, James wrote:
I often forget to use JUnit to test my classes, simply because it slips my mind because after I finish programming something I want to move on to the next thing as quickly as possible. James also found that using JUnit was problematic at times, due to his lack of experience with JUnit and the test first paradigm. JUnit testing is what I have had the most problems with as I am not used to doing that kind of program testing. For James, refactoring was the most enjoyable of the XP practices. He stated using the practice was more helpful when trying to understand concepts, and improving the solutions to tasks. At the end of semester survey about XP practices, James wrote that simple design was the most helpful: …meant code was generally easier to read and easier to see the logic behind it. It was observed that James pair programmed well, regardless of the skill level of his partner. He always ensured that his partner was involved in the act of programming, and not watching him as he worked. With students of less ability than he did he was able to explain how they were solving the problem, and he encouraged them to make suggestions. James’ only problem with pair programming was that once one part of a task was completed he got distracted and wandered away from his partner.
4.4
Phillippa
Phillippa is a student who struggled with programming in the first semester and was repeating the subject. Her understanding of basic programming concepts at the start of the semester was quite poor, as was her skill level. The results of the start of semester quiz showed that there were many areas of incomplete understanding, for example when to use a looping construct or the purpose of a constructor. Phillippa’s results on the end of semester quiz were better and she showed an improved understanding of the concepts taught, and could explain them in detail. This good understanding of the concepts did not always translate to an ability to implement them. However her results for the subject were vastly improved on her previous attempt at the subject. The results of Phillippa’s first exam were poor, but by the second exam her understanding of the concepts was better, and her results showed this. Unfortunately although she showed improvement, it was not enough to pass the exam. Pair programming was Phillippa’s preferred XP practice and she found that learning the concepts and implementing them was much easier when pair programming. A partner with a similar level of motivation to learn was an important factor in the success of pair programming for Phillippa. When answering the reflection questions Phillippa stated that she also preferred to work with someone stronger than she is so
that she can learn from them. This sentiment was expressed in the survey on the perceptions of XP practices. To be able to pair with someone who knows more than I do in this subject, so that I can learn from it. Phillippa felt strongly about using pair programming, but found that test first was more difficult, and rarely wrote test cases unless prompted to do so. When asked if she wrote JUnit test cases for her code, Phillippa responded: Only when the teacher request for it. It is good to see the green, I will get real worry to see the red. Phillippa stated that she found simple design and refactoring helpful when learning the object oriented concepts of inheritance, polymorphism and interfaces. Observations of Phillippa during the course of the semester found that she was a passive participant in pair programming. When pairing with a stronger student Phillippa tended not to question any decisions and was content to observe her partner programming, unless directed to swap roles. When pairing with someone of a similar skill level, Phillippa was only a little more proactive in the partnership, still relying on her partner to take the lead in finding solutions.
4.5
John
John was repeating the subject, having failed the subject the previous semester. His results in his previous attempt were quite poor and he did not show an understanding of the programming skills previously covered in the introductory subject. John’s results from the start of semester quiz showed that despite repeating the subject he still struggled with basic programming skills and he was unable to answer most of the questions on the quiz. Unfortunately for John, by the end of the semester quiz he had not progressed very far. In some areas his understanding was quite good, but in others very poor. For example, John was able to explain the difference between abstract and concrete classes, but could not alter a class declaration to make it an abstract class. John did not answer many of the questions. In his reflection questions, John claimed that pair programming was the most useful XP practice. He found that interacting with a partner when attempting to solve problems was a way in which he could improve his programming. I found pair programming useful because it help each other communicate easier which means that solving problems and coding were made easier. John said that the use of simple design was helpful in explaining the concepts of inheritance, classes and interfaces. As with other students test first proved to be difficult for John to master, and unless directed, he did not complete test cases.
At time I would use it if it were necessary, other than that no. Observations made of John while pair programming revealed that he was not active in the process, regardless of his partner’s ability. It did not matter what role John was playing in the pair, he would wait for his partner to dictate what they were to do. This caused problems especially with students of similar ability to John, as the pair stagnated, and could not get simple tasks completed.
4.6
Petra
Petra’s results at the start of semester quiz showed that she had a very basic level of understanding of the concepts taught in the introductory programming subject. Petra came from a different course, and completed a different introductory programming subject. By the end of the semester Petra demonstrated a better understanding of programming concepts in general, and an average understanding of the concepts taught during the semester. Her exam results reflected this understanding and she just passed the subject. For Petra, as with Phillippa, pair programming was the XP practice that was most helpful. Important factors for the success of pair programming according to Petra were: similar understanding of concepts; compatibility with partner; and ensuring both partners spent equal time in each role. Petra found it difficult to find anyone to pair program with outside of class time. I am very enthusiastic and like pair programming however I don’t find a partner to do pair programming outside of class. As with many students, the test first process was difficult, but Petra used JUnit regularly to test classes that she wrote and she found that it was useful for both general class work and for completing assignment work. Petra felt that simple design was indeed helpful to her in the explanation of object oriented concepts. Refactoring also helped her understand and improve her code. Observations made of Petra during class, were that she pair programmed particularly well with those who had a similar skill level. She was able to be quite active in the process, contributing to the task at hand. When paired with a stronger student, she tended to be more passive in the partnership, satisfied to simply watch her partner, unless directed to change roles.
4.7
Case Study Reflection
There were common themes that appeared in the case studies, regarding which of the practices were more popular, or considered more successful. The participants’ reactions to the different XP practices varied according to their programming abilities. Generally, stronger students preferred the practices of simple design and refactoring over pair programming, and weaker students showed a preference for pair programming. None of the students showed a preference for a test first approach.
Pair Programming Pair programming was successful for all students when they were active participants in the process. For the students of lesser ability pair programming was the most enjoyable practice. These students found that sharing the burden of solving problems made tackling them less daunting, regardless of their partners programming ability. This meant they were able to successfully complete tasks that were set for a session. Strong students who said they did not enjoy the practice as much still chose to pair program when sessions were allocated as optional pairing classes. On these days, the students picked their own partners, and generally picked a student that they were friendly with outside of the classroom, and who had a similar level of motivation. The practice of pair programming showed benefits to the students, however some issues emerged. While students were learning how to pair program it was important they were comfortable with the person that were working with. Allowing students to choose their partners at the beginning of the semester will address these problems. By partnering with a student they already have a rapport with, this should improve the ability of the pair to find a ‘rhythm’. It should also allow the teacher the time to identify problematic and successful pairs. During this cycle students swapped partners almost every session and this did not give them enough time to find a rhythm with each partner. If a very passive student was paired with a similar student or if two disinterested students were paired together then the partnership faltered, and very little work was completed. Test Driven Development Test first programming was the most difficult practice for students. More time should have been spent on the fundamentals of testing, for example, creating test data and testing principles, before introducing JUnit. For the weaker students, JUnit was a stumbling block, and at times caused more problems than the Java code they were trying to test. Observations made of the stronger students, revealed they did not see the point in creating JUnit test cases. These students could not see how their code could have defects; they thought their code was infallible. The common issue raised with TDD was not necessarily with TDD as such, but with testing in general. Students were confused about how they were to test a piece of code. The stronger students claimed they knew the programs they wrote were going to work. The weaker students stated they were struggling to understand the exact purpose of the code, so determining how to test it was too difficult. Another problem for students was determining what they were testing for, and what data they had to use in the test. Conceptually TDD was difficult for the students to understand. Students found the process of writing a test before they had written the code a complex task. Finally JUnit itself was an added difficulty. JUnit was introduced very early in the semester, while the students were learning the testing principles. Learning the
infrastructure and mechanics of JUnit interfered with the learning of testing concepts. Simple Design Simple design was introduced as a technique for explaining concepts such as inheritance, abstract classes, interfaces and polymorphism. Most students said simple design was helpful to them understanding these concepts, but for the weaker students, this did not translate into understanding how to implement the concepts. The stronger students were able to implement simple design at different stages of programming, for example designing algorithms or creating class structures. They were able to take the XP approach of doing the simplest thing that will work, and then refine their solutions by refactoring. The weaker students, in contrast quite often added as many lines of code as possible to a method in the hope that something would work. The focus of simple design on high level design concepts was lost on the weaker students, though the stronger students were able to grasp the purpose. The implementation should have been broadened to include low level design, for example simple algorithms to solve coding problems. This would be more akin to the true XP meaning of simple design, which is “doing the simplest thing that will work”. Refactoring Stronger students found the practice of refactoring a useful and enjoyable one to implement. The three strong students from the case studies enjoyed the “tinkering” aspect of refactoring. These students gained the most benefit from refactoring using the technique to improve their overall program design, while not altering the functionality of the program. The weaker students in the class found refactoring code to improve the design difficult, as they were not comfortable with the code that they had written, and struggled to understand what they were trying to achieve with it anyway.
4.8
Recommendations for Action
The following section discusses recommendations for implementing the practices in future cycles. Pair Programming Pair programming findings are consistent with the findings of other researchers. This suggests that pair programming is a useful teaching technique. Refinements to the implementation of pair programming need to be looked at in coming semesters, for example the number of sessions students pair program with the same partner, and who designates the pairs. Recommendation 1: Students should be able to choose their own partners in the initial sessions, enabling them to establish a rhythm to pair programming. An important factor with pair selection is that the partners have a similar motivation level. By giving the students the choice they can chose someone they know has this quality.
Test Driven Development Test driven development was the most difficult practice to introduce to the students. Testing certainly needs to be introduced to programming students, but whether or not they are capable of test first development is yet to be determined. The results from this study are inconclusive. Recommendation 2: The initial teaching sessions should focus on testing itself, rather than on TDD, allowing students to grasp concepts such as: creating test data; calculating expected results; executing a test; retrieving actual results; writing out simple test plans; what to test for; and importance of testing valid and invalid values. Recommendation 3: JUnit should be introduced afterwards, thereby allowing students to become comfortable with testing in general, and removing the added complexity of learning two new concepts at the same time. Simple Design The introduction of simple design was lost on some students. It could have been used more effectively by introducing the practice with low level design as well as higher level design. Recommendation 4: Simple design should be used at all stages of program design, not only when introducing concepts such as inheritance, but also when developing algorithms for simple problems. This may encourage the weaker students to embrace the simple design practice, and incorporate it into their coding. Refactoring Refactoring can be introduced as a tool for improving a student’s code at all levels. Students may understand the practice better if it is used to improve their algorithms and class design, thereby utilising it more frequently when coding. Recommendation 5: Student should be given examples of code that require refactoring, enabling them to practice the skill whilst learning. Refactoring, like simple design was more popular with the stronger students, but a way needs to be found to encourage all students to use refactoring to improve their code once they have developed their initial solutions.
5
Conclusions
Results drawn from this first Action Research phase have been varied. The introduction of the four XP practices seems to have benefited the weaker students in the course. These students had a better than expected understanding of the mechanics of programming and of the object oriented concepts. Problem solving was still an issue at the end of the semester, as was the students’ ability to implement abstract programming techniques in different situations. Currently there is another group of students undertaking the second semester programming subject, and they are gradually being introduced to the XP practices. Changes have been made to the way the practices are being
introduced to address the issues that were raised in the first phase of this research. It is hoped that with the refinement of the implementation of the XP practices that all students, regardless of their programming abilities, will have a positive learning experience.
6
Acknowledgements
The author’s would like to thank staff and students from the Department of Computing and Information Technology, Swinburne University of Technology, TAFE. In particular Carlo De Martinis, Head of the School of Engineering and Bruce Clifford, Head of the Department of Computing and Information Technology.
7
References
Astels, D., Miller, G., & Novak, M. (2002). A Practical Guide to Extreme Programming. Upper Saddle River: Prentice Hall. Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10), 70-77. Beck, K. (2001). Aim, fire [test-first coding]. Software, IEEE, 18(5), 87-89. Beck, K., & Andres, C. (2004). Extreme Programming Explained - Embrace Change (2nd ed.). Upper Saddle River: Pearson Education, Inc. Bevan, J., Werner, L., & McDowell, C. (2002). Guidelines for the use of pair programming in a freshman programming class. Paper presented at the Software Engineering Education and Training, 2002. (CSEE&T 2002). Proceedings. 15th Conference on. Carbone, A., Hurst, J., Mitchell, I., & Gunstone, D. (2001). Characteristics of programming exercises that lead to poor learning tendencies: Part II, Proceedings of the 6th annual conference on Innovation and technology in computer science education (pp. 93-96). Canterbury, United Kingdom: ACM Press. Edwards, S. (2004, 2004). Using Software Testing to Move Students from Trial-and-Error to Reflection-inAction. Paper presented at the SIGCSE'04, Norfolk, Virginia, USA. Edwards, S. H. (2003). Improving student performance by evaluating how well students test their own programs. J. Educ. Resour. Comput., 3(3), 1-24. George, B., & Williams, L. (2003). An initial investigation of test driven development in industry, Proceedings of the 2003 ACM symposium on Applied computing (pp. 1135-1139). Melbourne, Florida: ACM Press. Greca, A., Jovanovic, V., & Harris, J. (2003). Enhancing learning success in the introductory programming course. Paper presented at the Frontiers in Education, 2003. FIE 2003. 33rd Annual. Hedin, G., Bendix, L., & Magnusson, B. (2003). Introducing software engineering by means of Extreme Programming, Proceedings of the 25th International Conference on Software Engineering
(pp. 586-593). Portland, Oregon: IEEE Computer Society. Holcombe, M., Gheorghe, M., & Macias, F. (2001). Teaching XP for Real: some initial observations and plans. XP2001. Katira, N., Williams, L., Wiebe, E., Miller, C., Balik, S., & Gehringer, E. (2004, March 3-7, 2004). On Understanding Compatibility of Student Pair Programmers. Paper presented at the SIGSCE'04, Norfolk, Virgina, USA. Keefe, K., & Dick, M. (2004). Using Extreme Programming in a capstone project, Proceedings of the sixth conference on Australian computing education - Volume 30 (pp. 151-160). Dunedin, New Zealand: Australian Computer Society, Inc. McCracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan, D., Kolikant, Y. B.-D., Laxer, C., Thomas, L., Utting, I., & Wilusz, T. (2001). A multi-national, multi-institutional study of assessment of programming skills of first-year CS students SIGCSE Bull., 33(4), 125-180. Mills, G. (2000). Action research: a guide for the teacher researcher. Upper Saddle River, New Jersey: Prentice-Hall. Muller, M. M., & Hagner, O. (2002). Experiment about test-first programming. Software, IEE Proceedings[see also Software Engineering, IEE Proceedings], 149(5), 131-136. Neill, C. J. (2003). The extreme programming bandwagon: revolution or just revolting? IT Professional, 5(5), 62-64. Noble, J., Marshall, S., Marshall, S., & Biddle, R. (2004). Less Extreme Programming, Proceedings of the sixth conference on Australian computing education Volume 30 (pp. 217-226). Dunedin, New Zealand: Australian Computer Society, Inc. Nosek, J. T. (1998). The Case for Collaborative Programming. Communications of the ACM, 41(3), 105-108. Pancur, M., Ciglaric, M., Trampus, M., & Vidmar, T. (2003). Towards empirical evaluation of test-driven development in a university environment. Paper presented at the EUROCON 2003. Computer as a Tool. The IEEE Region 8. Shukla, A., & Williams, L. (2002). Adapting extreme programming for a core software engineering course. Paper presented at the Software Engineering Education and Training, 2002. (CSEE&T 2002). Proceedings. 15th Conference on. Thomas, L., Ratcliffe, M., & Robertson, A. (2003). Code warriors and code-a-phobes: a study in attitude and pair programming. Paper presented at the Proceedings of the 34th SIGCSE technical symposium on Computer science education, Reno, Navada, USA. Thomas, L., Ratcliffe, M., Woodbury, J., & Jarman, E. (2002). Learning styles and performance in the introductory programming sequence, Proceedings of the 33rd SIGCSE technical symposium on Computer
science education (pp. 33-37). Cincinnati, Kentucky: ACM Press. Wake, W. C. (2001). Extreme Programming Explored. Upper Saddle River: Addison-Wesley. Williams, L. (1999). But, isn't that cheating? [collaborative programming]. Paper presented at the Frontiers in Education Conference, 1999. FIE '99. 29th Annual. Williams, L. (2000). The Collaborative Software Process. Unpublished PhD, The University of Utah. Williamsons, K., Burstein, F., & McKemmish. (2002). The two major traditions of research. In K. Williamsons (Ed.), Research methods for students, academics and professionals (2nd ed.). Wagga Wagga, New South Wales: Centre for Information Studies, Charles Sturt University. Wilson, J. D., Hoskins, N., & Nosek, J. T. (1993, February 2003). The Benefits of Collaboration for Student Programmers. Paper presented at the 24th SIGCSE Technical Symposium on Computer Science Education.
