Extreme Programming: Tips and Advantages

What Is Extreme Programming?

Extreme Programming (XP) is an Agile software development methodology that is intended to improve software quality and responsiveness to changing customer requirements. It emphasizes business results first and takes an incremental “get something started” approach to building the product using continual testing and revision. It advocates frequent releases in short development cycles and is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. It simplifies and speeds up the process of developing new software, making it possible to launch a new product as fast as possible with a solid MVP. Extreme Programming is really about bringing efficiency in the coding process and providing customers with maximum value.

Like we said, Extreme Programming is part of the Agile methodology. It shares all Agile principles, including strong customer involvement in the software development process, good communication inside teams, and iterative cycles of development.

Extreme Programming is about putting individuals and interactions over processes and tools, working software over documentation, and customer collaboration over contract negotiation, and responding to change over following a plan. It is based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune practices to their unique situation.

In Extreme Programming, instead of delivering everything you could possibly want on some date far in the future, you deliver the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements.

Extreme Programming was the first Agile methodology to truly challenge traditional Waterfall methods. It changed traditional requirements-gathering techniques, brought testing to the forefront of the delivery process, and helped popularize core software engineering practices like automated testing, refactoring, continuous integration, and test-driven development.  

History and Values of Extreme Programming

XP was conceived and developed by Kent Beck, who wrote Extreme Programming Explained, the book based on his concept. The book addresses the issues faced by small development teams working in an environment of ever-changing requirements. Beck emphasizes that in order to write code, you have to write a test for it first so that you will know when it succeeds. Beck also introduces the relatively novel idea that code should be written by pairs of programmers, forcing the main programmer to describe the code to the other programmer and perhaps stimulate further ideas. Normally, XP is for teams between two and 12, though larger projects of 30 have reported success as well.

Beck’s fundamental idea is to start simply, build something real that works in its limited way, and then fit it into a design structure that is built for further code building. The XP team includes not only the developers but also the managers and customers, all working together elbow-to-elbow.

Values that drives the XP lifecycle are:

• Continual communication with the customer and amongst the team.

• Simplicity and focusing on the minimalist solution.

• Frequent feedback through unit testing and acceptance testing.

• Courage to take on problems proactively and to integrate testing and changes in the development phase.  

How Does Extreme Programming Work?

Normally, iterations in XP consist of five basic phases:

1. Planning.

2. Designing.

3. Coding.

4. Testing.

5. Listening.

Each of these phases includes a number of rules and practices. Let's look at them in more detail.  

1. Planning

The first phase of the Extreme Programming lifecycle is planning, in which customers meet with the development team to create user stories or requirements. The development team converts user stories into iterations that cover a small part of the functionality or features required. The programming team prepares the plan, time, and costs of carrying out the iterations, and individual developers sign up for iterations.  

On-Site Customers

On-site customers include real-life customers in the development process. The customers are always available to answer questions, provide the requirements, and set the priorities. As a result, the customer will be included and will avoid frustration caused by negative feedback and misunderstanding the requirements.   

The Planning Game

XP planning addresses two key questions in software development: "What will be accomplished by the due date?" and "What do we do next?" There are two key planning steps in XP addressing these two questions.

1. Release planning is a practice in which the customer presents the desired features to the programmers and the programmers estimate their difficulty and cost.

2. Iteration Planning is a practice in which the team is given direction every few weeks. XP teams build software in two-week iterations, delivering running useful software at the end of each iteration. During iteration planning, the customer presents the features desired for the next two weeks.  

Small Releases

The development team is required to make small frequent releases of working software that customers can evaluate. The first release includes the smallest set of useful features. Subsequent releases include newly added features. Small releases are important for both the customers and the development team, as they provide necessary feedback to continue in the right direction. It is important to release early and often, adding a few features each time.  

2. Designing

Using systems metaphors and standards on class names and methods and agreeing on uniform styles and formats is important to ensure compatibility among different team members.   

Simple Design

In the designing phase, XP concentrates on keeping things as simple as possible for as long as possible. No extra functionality is added early with the assumption that it might be used later on.

System Metaphor

A system metaphor is a common vision of the project in hand. The metaphor keeps the development team organized by providing a naming convention. A naming convention is very important as it helps in understanding the overall design of the system and helps developers reuse code. It saves time, as it makes it easier to find the functionality you are looking for and easier to know where to put certain functionalities.  

Refactoring

Refactoring is a process of continuous design improvement to keep the design as simple as possible and to avoid needless clutter and complexity. Refactoring removes redundancy and duplications and increases the code cohesion while decreasing its dependencies. Refactoring throughout the entire project saves time, increases quality, and improves understandability. It should be supported by comprehensive testing to ensure that nothing is broken.  

3. Coding

In the coding phase, XP concentrates on having coding standards to keep the code consistent and easy to read. The coding phase begins by creating test units. Pair programming is the basis of XP methodology. Each pair of programmers writes their code and then they integrate it together. The development team has collective code ownership. Each team member can change or refactor any part of the code.  

Coding Standards

Coding standards keep the code consistent and easy to read and refactor, which is very important in XP as it makes the code look as if one developer has written it. Everyone codes to the same standards. Ideally, you shouldn’t be able to tell who on the team has touched a specific piece of code by just looking at it.  

Pair Programming

Pair Programming is one of the practices that distinguishes the XP methodology. Each pair of programmers works together to develop certain functionalities. This increases software quality. In addition to better code quality, it helps communicate knowledge so that no one developer becomes a bottleneck.  

40-Hour Work Week

A 40-hour work week means that developers should not work more than 40 hours per week. There's no overtime. This gives developers a comfortable working environment with no pressure. In high-pressure times, up to one week of overtime is acceptable. Multiple weeks of overtime exhaust the developers and reduce their productivity.  

Continuous Integration

The XP team should maintain a fully integrated project. The integration process should be continued and carefully controlled. Developers should integrate tested code at least daily. CI often avoids diverging or fragmented development efforts in which developers are not communicating with each other about what can be reused or shared. Continuous Integration ensures that everyone has the latest version of the project. It also avoids and detects compatibility problems early.  

Collective Code Ownership

The development team should have collective code ownership. Each team member can change or refactor any part of the code. It ensures that no one developer becomes a bottleneck for changes and it allows programmers to reuse any functionality that might be required by multiple user stories.  

4. Testing

Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice test-driven development.

Testing in XP comes in two forms: unit tests and customer tests.

1. Unit Testing. Unit tests are automated tests written by developers to test functionality as they write it. Unit tests are very important as they can save a large amount of effort. 
2. Acceptance Testing. Acceptance tests, or customer tests, are specified by the customer to test that the overall system is functioning as planned. Automated testing results in much better overall quality. Acceptance tests are tests done by customers to ensure that the overall system contains all the required features. Acceptance tests are done at each iteration of the process. 

5. Listening

The basis of extreme programming is a continuous mechanism of customer involvement through feedback during the development phase. Programmers must listen to what the customers and project managers need the system to do and what business value they need to provide. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem can be solved.

Roles in Extreme Programming

• Tracker. The tracker goes around and asks each programmer how he or she is doing, listens to the answer, and takes action if things seem to be going off track. Actions include suggesting a CRC session, setting up a meeting with the customer, or asking a coach or another programmer to help.
• Customer. The customer writes user stories, specifies functional tests, sets priorities, explains stories, and views CRC sessions.
• Programmer. The programmer estimates stories, defines engineering tasks from stories, estimates how long stories and tasks will take, and implements stories and unit tests.
• Tester. The tester implements and runs functional tests, graphs results, and makes sure people know when test results decline.
• Coach. The coach schedules meetings, makes sure the meeting process is followed, and records results of each meeting and passes them to the tracker.

Some roles can be combined. For example, the same person could have the coach and the tracker role. Some roles probably should not be combined, like programmer and tracker. The coach probably shouldn’t be combined with anything other than the tracker. 

Advantages of Extreme Programming

The greatest advantage of Extreme Programming is that it allows software development companies to save costs, frustration, and time by eliminating unproductive activities. It allows developers to focus on coding.

One of the major advantages of Extreme Programming is that it reduces the risks related to programming and project failure. XP ensures that the client gets exactly what they want.

Simplicity is another advantage of Extreme Programming projects. Developers who prefer to use this methodology create extremely simple code that can be improved any time.

The most basic advantage of XP is that the whole process is visible and accountable. Developers make concrete commitments about what they will accomplish and show concrete progress.

XP means offering constant feedback, demonstrating the software early and often, listening carefully, and making any changes needed. Sprints help the team move in the right direction.

XP creates working software faster. Regular testing at the development stage ensures detection of all bugs, and the use of customer-approved validation tests ensures the implementation of only what the customer wants — nothing more.

Extreme Programming helps increase employee satisfaction and retention. Extreme Programming is a value-driven approach that sets fixed work times with little scope for overtime. The breakdown of project scope into subcomponents combined with constant customer feedback prevents the accumulation of work to be completed before a tight deadline.

Finally, XP supports teamwork. Everyone is part of the team. Team members work together on everything from requirements to code. Developers work in pairs and never feel alone or forgotten.