Extreme Programming: Software development to the extreme

These days, there are many different offshoots of agile software development. In addition to scrum and kanban, extreme programming is another method that’s always being discussed and implemented. What’s makes this approach to development so extreme?

Extreme programming (XP) is considered the most radical form of agile software development, which is why it’s called “extreme.” There is probably no other methodology as agile as XP, least of all traditional programming practices. Extreme programming is distinctly different from other approaches such as the waterfall model which has a variety of problems according to the inventors of XP. In the mid-1990s, software developers Kent Beck, Ward Cunningham and Ron Jeffries decided to revolutionize traditional development practices and go in a new direction.

Extreme programming is geared to the customer’s requirements. This might sound like a given at first, but traditional software development doesn’t always cater to customer needs. Things get even more difficult when these requirements change on a regular basis. XP also tries to encourage creativity in developers and accepts mistakes as a natural part of workflow.

Like other agile methods, XP is also based on iterative processes. XP breaks with the practice of completing a large project from start to finish in one go and investing many months of work only to find afterwards that the final product isn’t right. Instead, work is continuously tested, discussed and released in short cycles. This way, mistakes can be detected and eliminated quickly.

XP has a very clear framework for meeting requirements. It is based on a variety of values, principles and practices. In addition, people are assigned specific roles so that tasks are clearly delegated.

XP uses five values to try to change the general attitude toward programming. The team as a whole should adopt a certain mindset in order to collaborate as effectively as possible and create an excellent product.

Communication is important in XP, both between team members and between developers and customers. By continuously sharing information, teams can address problems immediately. Everyone involved must be in communication with each otherat all times in order to detect errors early on. Communication also ensures that everyone shares the same level of knowledge and feels committed to the project. Face-to-face conversations are preferred over written messages.

In XP, programmers always strive for the simplest solution. This has many advantages: By focusing solely on essential factors, programmers don’t dwell on unimportant things. This also means developing only the features that are needed today instead of focusing on possible future requirements. That way, the team speeds up the development process. A lean product is also much easier to manage when it comes to enhancements and maintenance. Furthermore, the simplest possible code is easier to understand, and that supports communication: If the whole team understands the source code, it’s easier for them to communicate about it.

This value is closely linked to the emphasis on direct communication. The customer should be able to express criticism as often as possible. Extreme programming also treats messages from the system (logs) as feedback. In order to create a culture of feedback that supports XP, it’s important to think in small steps: The team works in short cycles, continuously tests the code and presents each update to the customer at frequent intervals. This way, the team can make changes and fix bugs early on.

Extreme programming defines courage as the willingness to tell the truth, even if it might be unpleasant. Any errors in the product have to be pointed out, even if you yourself are responsible for them. A team that works according to XP values does not make excuses. Nobody on the team should try to minimize their involvement in a mistake because everybody is working toward a common goal. Moreover, this value means having the courage to change organizational structures, to question your own methods, to accept criticism and completely rewrite code, if necessary.

Mutual respect is necessary in order for the team to work in harmony and deliver excellent work. Respect also means that one developer doesn’t sabotage the work of another by altering it. Respect extends beyond the team to the customer. You have to take other peoples’ concerns seriously in order to respond to them appropriately. Finally, managers should also show respect for the development team and ensure that employees have the necessary skills and resources.

Principles are between values and practices in extreme programming. They link the abstract with the concrete. Principles are derived more or less from the values described above.

Teams should obtain feedback as early as possible and implement changes as quickly as possible. Programmers should take action in response to feedback from the system itself (when testing code) within seconds or minutes rather than collecting the feedback first. Teams should obtain feedback from customers and take action within days or weeks.

The principle of simplicity basically corresponds to the value of simplicity, but with more specific instructions for putting the concept into practice. Two methods are used:

• You ain’t gonna need it (YAGNI): To avoid unnecessary work, programmers shouldn’t add functionality unless it’s specifically requested.
• Don’t repeat yourself (DRY): You should avoid redundancy and design your code so that a change only has to be made once and not in several places.

In extreme programming, changes are always made in small steps. Instead of applying big updates all at once to eliminate multiple sources of error, the team addresses problems incrementally. This ensures that the team can respond faster and that the changes are easier to understand. This principle extends beyond program code: Changes in design or even in the structure of the team itself should be made in small, incremental steps.

Since extreme programming focuses heavily on the customer, the customer’s change requests have high priority. That means the entire team needs to have a positive attitude toward these changes rather than standing in their way. The team should actually encourage the customer to make change requests rather than trying to dissuade the customer.

This one might sound obvious, but it’s very important for the success of extreme programming: The team needs to produce high-quality work. The customer decides what high quality is. However, effective management is required in order to facilitate quality work. If all the factors are right and the team is satisfied with their work, it will have a positive effect on morale.

XP practices are very specific instructions and methods. Whereas the values and principles presented here are also used in other agile methodologies, the specific practices of extreme programming are the differentiating features of this method. They too have changed slightly over time and vary depending on the source you consult. Practices are generally divided into four different areas.

Development teams work in extremely short cycles in extreme programming. This way, the code they write can be tested over and over again. Test-driven development is unique because it requires that developers write a test environment before the actual source code is written. Code that doesn’t pass this test cannot be developed further. At this point, the feedback comes from the system itself.

The Planning Game is a meeting that takes place at the beginning of each development phase. The team and customer meet to discuss the work completed so far, give feedback, and talk about future features. Tasks are then assigned.

The concept of an on-site customer also ensures regular feedback. Ideally, at least one representative of the customer should be a permanent part of the team in order to answer questions quickly or to introduce ideas and help establish priorities.

Finally, pair programming ensures ensures that two developers always work on the same code at the same time, based on the premise that two heads are better than one. While one programmer writes the code, the other reviews the source code, gives suggestions for improvement and points out errors. Although this method is very costly because it uses two people to perform one task, the resulting code is ultimately better and requires fewer rewrites.

XP teams continuously revise their code. The purpose of this refactoring is to improve the source code as well as remove repetitions and unnecessary parts of the code. This optimized code is easier to understand, even for outside readers, and is less prone to errors.

In extreme programming, teams use continuous integration and other agile methods to continuously integrate new code into the overall project. Developers merge their work with the overall project several times a day. This ensures that the work of individual team members is continuously reviewed and everyone is working on the latest build.

Functioning programs and updates are released as early as possible, in line with the XP values. Small releases also increase the frequency of feedback. Errors can be detected faster and eliminated with the next update. The customer constantly has the opportunity to test the latest code and to offer criticism and suggestions.

A simple design ensures that the code is easily understood by everyone involved. Anything that makes the source code unnecessarily complex must be removed. Extreme programming encourages developers to avoid duplication. The programmer’s goal should also be clear from the source code.

Coding standards are defined so that entire team can work hand in hand. These standards specify the style and format for source code. Programmers should be able to find their way around each other’s code and should always be able to understand who made which changes.

The ability to work together on the code strengthens collective code ownership: Developers view the code as a collective product instead of assigning individual responsibility for certain parts of the code and the errors it contains. This way, the entire team bears responsibility for errors as well as successes. This technique also encourages programmers to work on other developers’ code and contribute ideas.

Extreme programming uses the system metaphor technique to further improve understanding of the source code. This practice involves describing the project in the simplest terms possible, including the use of metaphors. It also involves ensuring that naming conventions for objects, classes or functions in the code are as self-explanatory as possible. With this practice, anyone who joins the team later can quickly understand the code. Even non-programmers can get a general idea of the source code.

The teams’ well-being is important for the project’s success: Team members have to be well-rested and motivated to deliver high-quality work. To ensure this, extreme programming prescribes a 40-hour week. Overtime must be avoided at all costs and is only allowed if the following week does not include any overtime.

Extreme programming uses roles to share tasks and skills with everyone involved, both developers and customers.

Extreme programming is heavily focused on the customer. In fact, the customer is considered part of the team and always has at least one representative on site (on-site customer). The customer defines the product requirements but does not dictate how the objectives are to be achieved. The customer is merely responsible for prioritizing individual areas of the project. This also includes making its own wishes clear.

The role of the customer can be assumed by one person or by a team of different representatives of the customer. In practice, product managers or even marketing employees often perform these tasks (but always in line with the goal of the project).

The development team is not subdivided into different roles. In other words, anyone who actively creates the product falls under the role of developer. Depending on the requirements of the project, this role may include programmers as well as others involved in creating the product. Developers are responsible for developing the product as well as responding to the needs of customers by estimating time and effort, creating a schedule and planning implementation.

Developers also have the right to request help when needed, which can mean asking management for additional resources. Furthermore, XP practices for developers prescribe a 40-hour week. The project suffers if developers are overworked. As a result, the development team sets its own schedule.

The manager is the link between developers and customers. People in this role bring customers and developers together and moderate meetings like the Planning Game. In doing so, the manager ensures that everyone adheres to previously defined rules and general conventions for constructive discussions. The manager also assumes the role of a mediator, if necessary.

This role is sometimes referred to as tracker. That’s because the manager’s tasks include tracking key metrics (such as the time each person spends on the project).

The entire team (including the customer) must be able to handle extreme programming and consistently apply this methodology. A coach can help ensure that everyone has a shared understanding of processes. This person is not involved in actual product development and is merely an outside assistant similar to a scrum master. The team can review rules and practices with the coach during preliminary meetings. Ideally, the coach mentors the team throughout the entire development process, is available to answer questions and assists when uncertainty arises.

External consultants are often hired as coaches. A coach may also be someone from another department in the company. Dual roles (a developer who also fills the role of coach) should be avoided.

Extreme programming has given vital impetus to software development, but it’s not suitable for every scenario and team. XP assumes that the customer does not have a clear picture of the finished product at the beginning of the project. In these cases, the software can be agile, meaning it can be gradually planned and developed.

This way, the customer is satisfied: The development team works with the customer to find the right solution and the customer is involved in every step. Furthermore, developers can implement projects as they see fit, instead of constantly making compromises. However, it’s very difficult to use XP if the customer comes to the development team with a finished product description and a list of features.

Pair programming in particular can present problems for small teams because they don’t have the necessary resources for it. Plus, regular meetings with customers take up time that could be spent on actual programming. In an ideal situation, that doesn’t matter: The final product will clearly be better if the team has the time and resources they need.

However, in the real world, developers are constrained by limited budgets and clear deadlines. Furthermore, the customer may lack the interest or ability to get involved to the extent that XP requires.

However, if the circumstances are right for extreme programming, a team can deliver an excellent product with this method. Continuous testing results in stable software systems. The iterative approach, combined with a minimalist mindset, ensures that teams develop only those features that are truly needed for the project.