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:

Activities

XP describes four basic activities that are performed within the software development process.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Coding

The advocates of XP argue that the only truly important product of the system development process is code (a concept to which they give a somewhat broader definition than might be given by others). Without coding you have nothing.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Coding can be drawing diagrams that will generate code, scripting a web-based system or programming an object-oriented C# program that needs to be compiled.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (discussed in the next section) what solution is most suitable.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the exponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Testing

One cannot be certain of anything unless one has tested it. Testing is not a perceived, primary need for the customer. A lot of software is shipped without proper testing and still works (more or less).

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

In software development, XP says this means that one cannot be certain that a function works unless one tests it. This raises the question of defining what one can be uncertain about.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

• You can be uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete.
• You can be uncertain whether what you meant is what you should have meant. To test this uncertainty, XP uses acceptance tests based on the requirements given by the customer in the exploration phase of release planning.

Listening

Programmers don't necessarily know anything about the business side of the system development. The function of the system is determined by the business side. For the programmers to find what the functionality of the system should be, they have to listen to business.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Programmers have to listen "in the large": they have to listen what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Communication between the customer and programmer is further addressed in The Planning Game (see below).

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Designing

From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, that will not work. One can come a far way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~

One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~