There are four basic activities in Extreme Programming. They are −

• Coding

• Testing

• Listening

• Designing

These four basic activities need to be structured in the light of the Extreme Programming principles. To accomplish this, the Extreme Programming practices are defined.

These 12 Extreme Programming practices achieve the Extreme Programming objective and wherever one of the practices is weak, the strengths of the other practices will make up for it.

Kent Beck, the author of ‘Extreme Programming Explained’ defined 12 Extreme Programming practices as follows −

• The Planning Game

• Short Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40 hour Week

• On-site Customer

• Coding Standards

Four Areas of Extreme Programming

The Extreme Programming practices can be grouped into four areas −

• Rapid, Fine Feedback −

  • Testing

  • On-site customer

  • Pair programming

• Continuous Process −

  • Continuous Integration

  • Refactoring

  • Short Releases

• Shared Understanding −

  • The Planning Game

  • Simple Design

  • Metaphor

  • Collective Ownership

  • Coding Standards

• Developer Welfare −

  • Forty-Hour Week

In this chapter, you will understand the Extreme Programming practices in detail and the advantages of each of these practices.

Extreme Programming Practices at-a-glance

The following diagram shows how Extreme Programming is woven around the Extreme Programming practices −

The Planning Game

The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The Planning Game is toqQuickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.

Business and development need to make the decisions in tandem. The business decisions and the development’s technical decisions have to align with each other.

Business people need to decide about −

• Scope − How much of a problem must be solved for the system to be valuable in production? The businessperson is in a position to understand how much is not enough and how much is too much.

• Priority − If you are given an option, which one do you want? The businessperson is in a position to determine this, more than a developer with inputs from the customer.

• Composition of releases − How much or how little needs to be done before the business is better off with the software than without it? The developer”s intuition about this question can be wildly wrong.

• Dates of releases − What are important dates at which the presence of the software (or some of the software) would make a big difference?

Technical people need to decide about −

• Estimates − How long will a feature take to implement?

• Consequences − There are strategic business decisions that should be made only when informed about the technical consequences. Development needs to explain the consequences.

• Process − How will the work and the team be organized? The team needs to fit the culture in which it will operate. The software must be written well rather than preserve the irrationality of an enclosing culture.

• Detailed Scheduling − Within a release, which stories should be done first? The developers need the freedom to schedule the riskiest segments of development first, to reduce the overall risk of the project. Within that constraint, they still tend to move business priorities earlier in the development, reducing the chance that important stories will have to be dropped towards the end of the development of a release due to time constraints.

Thus, plan is a result of collaboration between the customer, businessperson and the developers.

The Planning Game – Advantages

The Planning Game has the following advantages −

• Reduction in time, wasted on useless features

• Greater customer appreciation of the cost of a feature

• Less guesswork in planning

Short Releases

You should put a simple system into production quickly, and then release new versions in very short cycles. Every release should be as small as possible, so that it is −

• Achievable in a short cycle

• Contains the most valuable and immediate business requirements

• A working system

The duration of the short cycle may vary with the software that needs to be built. However, it needs to be ensured that the minimum possible duration is chosen.

Short Releases – Advantages

The advantages of Short Releases are −

• Frequent feedback

• Tracking

• Reduce chance of overall project slippage

Metaphor

According to Cambridge online dictionary- A Metaphor is an expression, often found in literature that describes a person or object by referring to something that is considered to have similar characteristics to that person or object. For example, ‘The mind is an ocean’ and ‘the city is a jungle’ are both Metaphors.

You should guide the entire development with a simple shared story of how the whole system works. You can think of metaphor as the architecture of the system to be built in a way that it is easily understandable by everyone involved in the development.

The metaphor consists of domain specific elements and shows their interconnectivity. The language used is the domain language. To identify the technical entities, the words used in the metaphor need to be taken consistently.

As the development proceeds and the metaphor matures, the whole team will find new inspiration from examining the metaphor.

The goal of a good architecture is to give everyone a coherent story within which to work, a story that can easily be shared by both the business and the technical members.Hence, in Extreme Programming, by asking for a metaphor, we are likely to get an architecture that is easy to communicate and elaborate.

Metaphor – Advantages

The advantages of Metaphor are −

• Encourages a common set of terms for the system

• Reduction of buzz words and jargon

• A quick and easy way to explain the system

Simple Design

The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.

The right design for the software at any given time is the one that −

• Runs all the tests

• Has no duplicated logic like parallel class hierarchies

• States every intention important to the developers

• Has the fewest possible classes and methods

To get a simple design, eliminate any design element that you can, without violating the first three rules. This is opposite to the advice- Implement for today, design for tomorrow. If you believe that the future is uncertain and you can quickly enhance the design, then do not put any functionality on speculation.

Simple Design – Advantages

The advantages of Simple Design are −

• Time is not wasted adding superfluous functionality

• Easier to understand what is going on

• Refactoring and collective ownership is made possible

• Helps keep the programmers on track

Testing

The developers continually write unit tests, which need to pass for the development to continue. The customers write tests to verify that the features are implemented. The tests are automated so that they become a part of the system and can be continuously run to ensure the working of the system. The result is a system that is capable of accepting change.

Testing – Advantages

The advantages of testing are −

• Unit testing promotes testing completeness

• Test-first gives developers a goal

• Automation gives a suite of regression tests

Refactoring

When implementing a feature, the developers always ask if there is a way of changing the existing code to make adding the feature simple. After they have added a feature, the developers ask if they now can see how to make the code simpler, while still running all of the tests. They restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. This is called Refactoring.

Refactoring – Advantages

The advantages of Refactoring are −

• Prompts the developers to proactively improve the product as a whole

• Increases the developer knowledge of the system

Pair Programming

In Pair programing, the entire code is written with two developers at one machine, with one keyboard and one mouse.

There are two roles in each pair −

• The first developer (the one with the keyboard and the mouse) thinks about the best way to implement this method right here.

• The other developer is thinks more strategically

  • Is this whole approach going to work?

  • What are some other test cases that might not work yet?

  • Is there some way to simplify the whole system so the current problem just disappears?

The pairing is dynamic. It means that the two Roles A and B may exchange their places, or they may pair up with other team members. More often, anyone on the team will do as a partner. For example, if you have a responsibility for a task in an area that is unfamiliar to you, you might ask someone with recent experience to pair with you.

Pair Programming – Advantages

The advantages of Pair Programming are −

• Two heads are better than one

• Focus

• Two people are more likely to answer the following questions −

  • Is this whole approach going to work?

  • What are some test cases that may not work yet?

  • Is there a way to simplify this?

Collective Ownership

In Extreme Programming, the entire team takes responsibility for the whole of the system. Not everyone knows every part equally well, although everyone knows something about every part.

If a pair is working and they see an opportunity to improve the code, they go ahead and improve it.

Collective Ownership – Advantages

The advantages of Collective ownership are −

• Helps mitigate the loss of a team member who is leaving.

• Promotes the developers to take responsibility for the system as a whole rather than parts of the system.

Continuous Integration

Code is integrated and tested many times a day, one set of changes at a time. A simple way to do this is to have a machine dedicated to integration. A pair with code ready to integrate −

• Sits when the machine is free.

• Loads the current release.

• Loads their changes (checking for and resolving any collisions).

• Runs the tests until they pass (100% correct).

Integrating one set of changes at a time helps in knowing who should fix a test that fails. The answer- is the present pair, since the last pair left the tests at 100%. They may have to throw away what they have done and start all over, as they might not have known enough to code that feature.

Continuous Integration – Advantages

The advantages of Continuous Integration are −

• Reduces the duration, which is otherwise lengthy.

• Enables the short releases practice as the time required before release is minimal.

40-Hour Week

Extreme Programming emphasizes on the limited number of hours of work per week for every team members, based on their sustainability, to a maximum of 45 hours a week. If someone works for more time than that, it is considered as overtime. Overtime is allowed for at most one week. This practice is to ensure that every team member be fresh, creative, careful and confident.

40-Hour Week – Advantages

The advantages of 40-hour week are −

• Most developers lose effectiveness past 40 hours.

• Value is placed on the developers’ well-being.

• Management is forced to find real solutions.

On-Site Customer

Include a real, live user on the team, available full-time to answer the questions, resolve disputes and set small-scale priorities. This user may not have to spend 40 hours on this role only and can focus on other work too.

On-Site Customer – Advantages

The advantages of having an onsite customer are −

• Can give quick and knowledgeable answers to the real development questions.

• Makes sure that what is developed is what is needed.

• Functionality is prioritized correctly.

Coding Standards

Developers write all code in accordance with the rules emphasizing-

• Communication through the code.

• The least amount of work possible.

• Consistent with the “once and only once” rule (no duplicate code).

• Voluntary adoption by the whole team.

These rules are necessary in Extreme Programming because all the developers −

• Can change from one part of the system to another part of the system.

• Swap partners a couple of times a day.

• Refactor each other”s code constantly.

If the rules are not followed, the developers will tend to have different sets of coding practices, the code becomes inconsistent over time and it becomes impossible to say who on the team wrote what code.

Coding Standards – Advantages

The advantages of Coding Standards are −

• Reduces the amount of time developers spend reformatting other peoples’ code.

• Reduces the need for internal commenting.

• Calls for clear, unambiguous code.