Extreme Programming - Supporting Practices

The Extreme Programming practices if implemented in isolation can be weak and thus, can fail. In Extreme Programming, all the practices need to be considered as a whole, so that they support each other. The weakness of one is covered by the strengths of others.

In this chapter, we will focus on the possible weakness of each practice if implemented in isolation. We will see how Extreme Programming can support this practice to overcome the weakness when implemented in conjunction with other practices.

The Planning Game – Support from other XP Practices

In this section, we will see the weaknesses of the Planning Game are and how the other XP practices support it.

The Planning Game – Disadvantages

The disadvantages of the Planning Game are that you cannot possibly start development with only a rough plan and you cannot constantly update the plan as it would take too long and upset the customers.

The Planning Game with other XP practices

The other XP practices support the planning game in the following way −

In planning game, the customer is also involved in updating the plan, based on the estimates provided by the developers.
You make short releases so that any mistake in the plan would have at the most a few weeks or months of impact.
Your customer sits with the team, so they could spot potential changes and opportunities for improvement quickly (on-line customer).
Continuous testing helps the developers and the customer to decide what is required immediately.

Thus, you can start development with a simple plan, and continually refine it as you go along.

Short Releases – Support from other XP Practices

Short Releases – Disadvantages

You cannot possibly go into production after a few months. You certainly cannot make new releases of the system on cycles ranging from daily to every couple of months. This is because you take time to absorb new requirements, changes into the current code.

Short Releases with other XP practices.

The other XP practices support Short Releases in the following way −

The planning game helps you work on the most valuable stories, so even a small system will have business value.
Continuous integration makes the cost of packaging a release minimal.
Testing reduces the defect rate enough so that a lengthy test cycle is not required before a release.
You can make a simple design, sufficient for this release, not for all time.

Thus, you can make Short Releases, soon after the development begins.

Metaphor – Support from other XP Practices

You cannot possibly start development with just a metaphor. It may not have enough details there, and you may be wrong.

Metaphor with other XP practices

The other XP practices support Metaphor in the following way −

With pair programming, you will have quick concrete feedback from the implemented code and tests about whether the metaphor is working fine.
Your on-site customer is comfortable talking about the system in terms of the metaphor.
Continuous refactoring allows you to refine your understanding of what the metaphor means in implementation.
Simple design helps you to have a mapping with the metaphor.

Thus, you can start development with just a metaphor.

Simple Design – Support from other XP Practices

Simple Design − Disadvantages

You cannot possibly have just enough design for today's code and your design may not continue to evolve the system.

Simple Design with other XP practices.

The other XP practices support Simple Design in the following way −

Refactoring allows you to make changes.
With an overall metaphor, you are sure that the future design changes would tend to follow a convergent path.
Pair programming helps you to be confident that you are making a simple design that works.
40-hour week helps you to be focused on the right design.
Continuous unit testing and customer testing ensures that your simple design is on the track.

Thus, you can do the best possible design for today, without speculation.

Testing – Support from other XP Practices

Testing - Disadvantages

You may think that −

You cannot possibly write all those tests.
It can take too much time to write the tests.
Developers will not write the tests.

Testing with other XP practices

The other XP practices support Testing in the following way −

Simple design makes writing tests easy.
Refactoring allows you to decide on what tests are necessary.
With pair programming, even if you cannot think of another test, your partner can. You can allow your partner to run the tests handing over the keyboard and you feel confident when you see the tests all running.
Collective ownership ensures that a developer with required skills is working on any complex part for coding and testing.
Continuous integration and immediately running the tests for every set of changes made by a pair ensures −
- That the new code works if 100% tests pass, or
- That if any test fails, it is that pair’s code that is failing the system so that the changes can be immediately reversed and the pair can start afresh with coding with the clarity on the feature they are implementing.
Short releases ensure that a working system is available for the customer to run the tests and give feedback.
On-line customer will have time to run all the tests and provide feedback immediately on the working system.
Planning game ensures to take the feedback from the customer after testing to plan for the next release.

Thus, the developers and the customers will write tests. Further, the tests are automated to ensure the working of the rest of the Extreme Programming.

Refactoring – Support from other XP Practices

Refactoring - Disadvantages

You cannot possibly refactor the design of the system all the time. It would −

Take too long.
Be too hard to control, and
Most likely break the system.

Refactoring with other XP practices

The other XP practices support Refactoring in the following way −

With collective ownership, you can make changes wherever they are needed.
With coding standards, you need not reformat before refactoring.
With pair programming, you can have the courage to tackle a tough refactoring.
With a simple design, the refactoring is easier.
With metaphor, you can communicate easily.
With testing, you are less likely to break something without knowing it.
With continuous integration, if you accidentally break something, or if your refactoring conflicts with someone else's work, you come to know in a few hours.
With 40-hour week, you are rested and so you have more courage and are less likely to make mistakes.

Thus, you can refactor whenever you see the chance to −

Make the system simpler
Reduce duplication
Communicate more clearly

Pair Programming – Support from other XP Practices

Pair Programming - Weakness

You cannot possibly write all the code in pairs. It will be too slow. It makes the situation difficult if two people do not get along well.

Pair Programming with other XP practices.

The other XP practices support pair programming in the following way −

The coding standards reduce conflicts.
With 40-hour work, everyone is fresh and focused, reducing further the chance of unnecessary discussions.
The pairs write tests together, giving them a chance to align their understanding before tackling the implementation part.
Metaphor helps the pairs to ground their decisions about naming and the basic Design
Simple Design enables the pair to have a common understanding.
Refactoring helps the pair to discuss and make combined decisions in making the system simple.
Continuous Integration gives a chance to the pair to correct in case of any mistakes and hence a partner will not object when the other does some experimentation.
Collective Ownership enables the team to mix and match and allows them to maintain a cordial relationship.

Thus, you can write all the code in pairs. On the other hand, if the team works in solo, they are more likely to make mistakes, overdesign and overlook the other practices.

Collective Ownership – Support from other XP Practices

Collective Ownership – Disadvantages

You cannot possibly have everybody changing anything anywhere in the System. For, it is possible to break the System unknowingly and the cost of integration will go up dramatically.

Collective Ownership with other XP practices

The other XP practices support Collective Ownership in the following way −

Continuous Integration reduces the chances of conflicts.
Testing reduces the chance of breaking things accidentally.
With Pair Programming, you are less likely to break the code, and developers learn faster what they can profitably change.
With Coding Standards, you will not have conflicts on the code.
With Refactoring, you maintain the system simple so that everyone understands it.

Thus, you can have anyone change code anywhere in the system when they see the chance to improve it. On the other hand, without collective ownership the rate of evolution of the design slows dramatically.

Continuous Integration - Support from other XP Practices

Continuous Integration – Disadvantages

You cannot possibly integrate after only a few hours of work, as integration takes long and there are too many conflicts and chances to accidentally break something.

Continuous Integration with other XP practices

The other XP practices support Continuous Integration in the following way −

Testing quickly helps you to know that you have not broken anything.
With pair programming, there are half as many streams of changes to integrate.
With refactoring, there are smaller pieces, reducing the chance of conflicts.
With coding standards, the code will be consistent.
Short releases ensure immediate feedback on the system.
Collective ownership ensures that whoever changes the code and integrates will have a whole view of the system.

Thus, you can integrate after a few hours. On the other hand, if you do not integrate quickly, then the chance of conflicts rises and the cost of integration goes up steeply.

40-Hour Week – Support from other XP Practices

40-Hour Week – Disadvantages

You cannot possibly work 40-hour weeks. You cannot create enough business value in 40 hours.

40-Hour Week with other XP practices

The other XP practices support the 40-hr week in the following way −

The planning game provides you what more valuable work to do.
The combination of the planning game and testing ensures that you have to work on only what you thought.
Simple design and refactoring allows you to stay focused and complete on time.
Pair programming helps you to work on what you can do, sharing the other work with your partner.
The practices as a whole help you develop at top speed, and hence you cannot go any faster.

Thus, you can produce enough business value in 40-hour weeks. On the other hand, if the team does not stay fresh and energetic, then they won't be able to execute the rest of the practices.

On-Site Customer – Support from other XP Practices

On-Site Customer – Disadvantages

You cannot possibly have a real customer full-time on the team, not producing any value. They can produce far more value for the business elsewhere.

On-Site Customer with other XP practices

The other XP practices support the on-site customer in the following way.

They can produce value for the project −

In Planning Game, by making priority and scope decisions for the developers.
With Metaphor, to bring clarity for the developers on the domain.
In testing, by writing acceptance tests and by performing acceptance testing after every short release.

Thus, they can produce more value for the organization by contributing to the project.

Coding Standards – Support from other XP Practices

Coding Standards – Disadvantages

You cannot possibly ask the team to code to a common standard as developers are usually individualistic.

Coding Standards with other XP practices

The other XP practices support Coding Standards in the following way −

Pair Programming makes them adapt to the necessary Coding Standards easily.
Continuous Integration enforces them to follow standard so that the code is consistent.
Collective Ownership encourages them to align to the standard to make changes when and wherever necessary.