What is Extreme Programming?

Overview

Extreme Programming (XP) is a software development methodology, one of the many agile methodologies. It focuses on small iterative releases and uses user stories to gauge requirements instead of formal software specifications.

XP includes a set of qualities and practices proven to improve software engineering and was introduced by Ken Beck in the 90s. His goal was to find ways to produce high-quality code quickly while being flexible to users’ changing requirements. He published his refined approach in his book, Extreme Programming Explained: Embrace Change.

Phases of XP

On a high level, XP consists of 4 main activities, which iterate continuously:

• Designing/planning: For effective software engineering, coding and testing alone are not enough. It is imperative to plan ahead and design an efficient system with simplicity at its core.
• Coding: One of the main activities in software engineering. Coding involves writing the actual code for a program or application following good coding practices.
• Testing: After completing a program component, it is important to test it individually as well as in coherence with the entire system (unit testing). After successful technical testing, acceptance testing must be carried out, which ensures that the end result is in line with the customer’s expectations and needs.
• Listening: Listening for feedback during the development process is a fundamental element of XP. User’s changing requirements must be expected, heard, and integrated into the existing system smoothly and quickly.

To increase cooperation between teams and ensure a high-quality output, Ken Beck highlighted a set of values and principles which are to be upheld in each stage of XP.

Values:

• Communication: Knowledge is universally shared among the team through verbal communication, shared development, feedback, and so on. This allows the entire team to be on the same page as they have a comprehensive view of the entire project.
• Simplicity: Developers strive to maintain simplicity in both the quality of the code as well as the features they implement. This is done to ensure that maximum output while saving time and effort instead of working on things that are too far ahead.
• Feedback: XP follows the rapid feedback principle, where feedback, when done frequently and promptly, is considered to be of paramount importance. By conducting frequent unit testing, appropriate feedback can be received, which then guides the project on the best trajectory. 
• Respect: A project consists of individuals, and each individual has a common goal at heart. Therefore, every contribution by everyone is to be considered of value.
• Courage: Many aspects of the project involve courage, whether it is to stay persistent when faced with a difficult problem or to be able to change or remove code following a change in user requirements.

Principles:

• Incremental changes: In contrast to implementing big changes at once, XP prefers small changes implemented step by step (in iterations).
• Assumed simplicity: Developers approach the problem as if the solution is extremely simple. The focus should be on what can be done “now.”
• Rapid feedback: Feedback is to be received, understood, and worked on rapidly instead of having gaps and delays.
• Embracing change: Developers should be ready to embrace any change brought by the user and should plan to integrate it in future iterations.
• Quality work: The team members work well together and enjoy what they do. They are proud of the product and think that it adds value.

XP practices:

Other than principles and values, XP also defines a set of practices that distinguish it from other methodologies. These practices are designed to work in conjunction and complement each other to produce high-quality results:

1. Metaphor: To ensure ease of understanding among all stakeholders, an easy-to-understand story of how the system works should be tailored. This is done through consistent and intuitive naming of classes and methods throughout the system.
2. Release Planning: A meeting is to be held at the beginning of a development iteration between developers and users. A plan for the upcoming iteration is drafted, and tasks are assigned.
3. Testing: Developers write unit tests before developing a component, which needs to be passed before development can continue. These tests, in turn, allow rapid feedback to be received.
4. Pair Programming: Coding is done in pairs, where one person writes the actual code while the other guides and proofreads. This leads to a higher quality of resulting code.
5. Refactoring: Previous code is to be structured as development proceeds. This is done to either make the existing code simple and efficient or to respond to a changing user requirement.
6. Simple Design: Simplest design path is to be taken when possible. If a simpler approach to a previously implemented component is discovered, it should be updated immediately.
7. Collective Code Ownership: Ownership of the code is given to the entire team as a whole. This allows each member to be able to understand, review, and change any aspect of the code.
8. Continuous Integration: To ensure that the entire team is working on the latest version of the software, any code written should be integrated into the main as it is developed and tested, as frequently as possible.
9. On-site Customer: An end-user/customer must always be available to the development team at any given time. This customer will provide immediate feedback to the developers and will help them understand user requirements.
10. Small Releases: The software is to be delivered in small functional releases, with the most valuable and simple components developed first. This allows for prompt feedback and early detection of bugs.
11. 40-Hour Work Week: To maintain a healthy work-life balance while giving the best possible output, XP suggests a 40-hour workweek for its developers.
12. Coding Standards: Good and consistent coding practices must be maintained throughout the development team. This allows for an easier understanding of code and results in better code ownership among the team.