Extreme Programming

Extreme Programming (XP) is a method or approach to software engineering and the most popular of several agile software development methodologies. It was formulated by Kent Beck, Ward Cunningham, and Ron Jeffries. Kent Beck wrote the first book on the topic, Extreme programming explained: Embrace change, published in 1999. The second edition of the book, which appeared in 2005, delves more into the philosophy of Extreme Programming and describes it as being:

Principles

The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Rapid feedback

Feedback is most useful if it is done rapidly. The time between an action and its feedback is critical to learning and making changes. In Extreme Programming, unlike traditional system development methods, contact with the customer occurs in small iterations. The customer has clear insight into the system that is being developed. He or she can give feedback on the progress and steer the development where is needed.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Assume simplicity

Assuming simplicity is about treating every problem as if it can be solved "extremely simply". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Incremental changes

The advocates of Extreme Programming say that Rome wasn't built in a day: making big changes at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. By making many little steps the customer has more control over the development process and the system that is being developed.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Embracing change

It is always certain that there will be uncertainty. The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~