What is Extreme Programming (XP)

XP is a lightweight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements. To some people, XP seems like just good common sense. So why the “extreme” in the name?

XP takes common sense principles and practices to extreme levels.

• If code reviews are good, we’ll review code all the time (pair programming).
• If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
• If the design is good, we’ll make it part of everybody’s daily business (redesigning).
• If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
• If architecture is important, everybody will work on defining and refining the architecture all the time (metaphor).
• If integration testing is important, then we’ll integrate and test several times a day (continuous integration).
• If short iterations are good, we’ll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).

XP makes two sets of promises

• To programmers, XP promises that they will be able to work on things that really matter, every day. They won’t have to face scary situations alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they won’t make decisions they aren’t best qualified to make.
• To customers and managers, XP promises that they will get the possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.

In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams—all at the same time.

What distinguishes XP from other methodologies?

• Early, concrete, and continuing feedback from short cycles.
• An incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
• The ability to flexibly schedule the implementation of functionality, responding to changing business needs.
• Reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
• Reliance on oral communication, tests, and source code to communicate the system structure and intent.
• Reliance on an evolutionary design process that lasts as long as the system lasts.
• Reliance on the close collaboration of programmers with ordinary skills.
• Reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
• Emphasis on the concept that 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.

The risk of software development

“Software development often fails to deliver and sometimes fails to deliver value”.  This failure has a huge economic and human impact. We need to find a new way to develop software.

The basic problem of software development is that it is risky. Here are some examples of risk:

• Schedule slips—the day for delivery comes, and you have to tell the customer that the software won’t be ready for another six months.
• Project cancelled—after numerous slips, the project is cancelled without ever going into production.
• The system goes sour—the software is successfully put into production, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.
• Defect rate—the software is put into production, but the defect rate is so high that it isn’t used.
• Business needs misunderstood—the software is put into production, but it doesn’t solve the business problem that was originally addressed.
• Business changes—the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing business problem.
• False feature set—the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money.
• Staff turnover—after two years, all the good programmers on the project begin to hate the program and leave.

How does XP address the risks listed above?

• Schedule slips—XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one- to four-week iterations of customer requested features for fine-grained feedback about progress. Within an iteration, XP plans with one- to three-day tasks, so the team can solve problems even during an iteration. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value.
• Project cancelled—XP asks the customer to choose the smallest release that makes the most business sense, so there is less to go wrong before going into production and the value of the software is greatest.
• The system goes sour—XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change (several times a day*), to ensure a quality baseline. XP always keeps the system in prime condition. Poor code is not allowed to accumulate.
• Defect rate—XP tests from the perspective of both programmers writing tests function/by-function and customers writing tests program-feature-by-program-feature.
• Business needs misunderstood—XP calls for the customer to be an integral part of the team. The specification of the project is continuously refined during development, so learning by the customer and the team can be reflected in the software. This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.
• Business changes—XP shortens the release cycle, so there is less change during the development of a single release. During a release, the customer is welcome to substitute new functionality for functionality not yet completed. The team doesn’t even notice if it is working on newly discovered functionality or features defined years ago.
• False feature set—XP insists that only the highest priority tasks are addressed.
• Staff turnover—XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates. The rules for who can make and change estimates are clear. Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible. XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction. Finally, XP incorporates an explicit model of staff turnover. New team members are encouraged to gradually accept more and more responsibility and are assisted along the way by each other and by existing programmers.

* In the early days of XP, system-wide integration testing was encouraged as a daily end-of-day activity every day to detect incompatible interfaces in the early stages so they can be reconnected before the separate sections diverged widely from coherent functionality. However, system-wide integration testing is now reduced to once a week (and sometimes even more). This largely depends on the stability of the overall interfaces in the system.