Extreme Programming (XP) is a lightweight software development method suitable for small teams working in projects characterised by incomplete or frequently changing requirements.

Cost of change - Change management

One of the (almost) universal hypothesis in software engineering is that the cost of change increases exponentially with time. The traditional approach (specification > design > development > validation cycle) thus concentrates most decisions at the beginning of the project, in an attempt to give the customer some guarantees on what he or she will obtain when the project ends.

Unfortunately, the field reality of this approach is often made of numerous strategic changes, specification and design mistakes, all becoming costly perturbations in a traditional process relying on the stability of the specifications. Change then becomes the source of budget overshoots, missed deadlines or, in the worse case, death of the project.

In an XP project, change is accepted and integrated as an element of the organisation.

XP uses team organisation and programming practices that allow the software to become extremely flexible. On the basis of very short iterative cycles, with XP it becomes even more valuable to make decisions as late as possible, using the results of the development itself as a feedback.

Consequently, the cost of change in an XP project increases slowly with time, rather than exponentially.

Customer implication

In an XP project, rather than seeing his role limited to functional specification phase, the customer returns to the central role of pilot of the development process. XP proposes to put the software in production very quickly (originally with very limited functionality, obviously) to give the customer a return on investment as early as possible, then to deliver successive new versions in a very short iterative cycle (typically every 2 weeks).

In each iteration, the customer chooses which functionality will be implemented next, collaborates with the developers to define his needs in detail, and rapidly receives a new version of the software integrating these evolutions. He or she keeps a permanent view on the development progress.

Communication is one of the fundamental values of XP. Priority is given to collaboration with the customer rather than contractual negotiations. Developers communicate with the end-users directly instead of trying to interpret detailed specifications.

The software itself serves as the basis on which new features to be integrated in the following iterations are defined. Therefore it becomes possible to detect and correct conceptual mistakes very early, and to drive the development based on experience fed back from the end-users.

Finally, the priority attributed to features is no longer driven by technical constraints, but rather by their business value. The efforts of the developers are focused on the most important business benefits right from the beginning of the project, allowing the customer to optimise the spending of his budget.

Selected examples of XP practices

Most of the principles applied in XP are best practices developed and field-proved by experienced programmers and project managers, some even in the context of traditional development. None of the XP practices is fundamentally revolutionary.

The innovation in the XP approach consists in organising proven practices into a global lightweight and coherent process where each individual practice reinforces the others, and to push the whole concept to the extreme (hence the name of the method).

Planning Game

XP makes the assumption that it is not possible to have a complete view of all of the needs and features at the start of a project. Both the customer and the developers are going to learn from the project, and this experience will be the source of changes and new features to which the XP method is fully open and prepared.

In the Planning Game, scope and priorities are determined by the customer for each development iteration. Developers estimate the duration and risk of the proposed tasks. Estimations are then compared to effective development time in order to tune and gain confidence in further iterations. Risky tasks are generally carried out first in order to mitigate the overall risk within the project time frame.

Test driven development

Developers write unit tests as they write code. These tests are the quality assurance of the software. Writing tests first guarantees that the code will be as simple and efficient as possible. Tests are the basis for refactoring and guarantee that changing or new requirements can be accepted even late in the development.

Pair Programming

In XP, all production code is written in pairs. Two programmers work together on one computer.

The advantages are:

Pair Programming may at first seem like a serious loss in efficiency. However, experience proves that in the medium and long term, the code produced is more efficient, better tested and contains less bugs. This then easily compensates the efforts otherwise necessary for bug finding and correction.

Constant refactoring

Refactoring is the technique of improving code without changing functionality. Refactoring guarantees that the code remains clean, simple and robust.

Simple design

Extra features and future functionality are not integrated in the development process if they are not used. The design is kept as simple as possible. Additional functionality is added only when effectively needed, using test-driven development and refactoring.

Continuous integration

New functionality is integrated several times a day, and run against existing and new test cases. This approach guarantees that there is a working product available at all times, and minimises the time spend on debugging.