Extreme programming (XP) is an agile development method that uses on-site customer collaboration, paired programming, and automated testing processes. XP is a widely used agile method that focuses on simplicity, internal communications, and customer feedback (Singh & Pandey, 2017). XP, which was presented by Beck in 1999, is one of the oldest of the agile methods (Anwer & Aftab, 2017). According to Munawar and Qureshi (2015), the advantages of XP are short iteration cycles, direct communication with an on-site customer, and continuous integration and testing. The disadvantages are that the practice is minimal documentation and the method is not suited for projects that involve reengineering (Munawar & Qureshi, 2015). According to Anwer and Aftab (2017), the XP method is challenging to use on large projects and projects of a critical nature. XP, although practiced before the concept of agile was defined, is an agile development process.
XP, much like scrum, uses iterative phases in the software development process. The first phase of XP is the initialization phase in which project team members gather requirements from customers that are directly involved with the team to determine project scope and cost (Anwer & Aftab, 2017). In the requirements gathering phase, the team uses story cards to document and describe the request and elicit dialogue with the customer (Baruah, 2015). In the second phase (analysis phase), the software team develops the architecture and iteration plan (Anwer & Aftab, 2017). Repeated cycles of code development and testing follow the requirements and analysis phase, and the code is integrated into a deliverable release once it achieves the functional request (Anwer & Aftab, 2017). Additionally, one of the critical distinctions in the XP development process is the concept of paired programming.
Paired programming is a development approach in which two programmers sit together, one assuming the role of the driver and the other, the navigator. Paired programming is a standard practice in XP in which two people collaborate in the coding process (Hohl et al., 2018; Kotaiah & Khalil, 2017; Meyer, 2018). The driver sits at the keyboard to type the code while the navigator oversees the code input, watching for syntax errors and ensuring the program meets the required deliverable (Chen & Rea, 2018). The programmer who is actively writing the code (driver) focuses on the completion of the current task (Chen & Rea, 2018). The navigator, who is overlooking the code writing, can judge the strategic direction of the work performed, offering ideas for improvement or potential future problems (Karthiekheyan, Ahmed, & Jayalakshmi, 2018). The approach uses two programmers to collaborate on a single code set, working together to complete a development request.
Paired programming can have an advantage over developers working independently. In paired programming, the driver and the navigator often change roles throughout the project (Chen & Rea, 2018; Haines et al., 2017). The benefits of paired programming are constant code review and the brainstorming of approaches during the code’s development (Karthiekheyan et al., 2018). According to Chen and Rea (2018), programmers can quickly catch and resolve errors, thus producing better code using a collaborative approach. Additionally, pairing an expert programmer with an average or novice programmer provides mentorship to the novice (Chen & Rea, 2018). However, teaming individuals who have the same expertise can cause counterproductive work (Haines et al., 2017). Therefore, the benefits of paired programming can be more significant when developers have different skill levels or experience.