Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.

    "Still, building minimal systems goes against the grain of many analysts and programmers, who pride themselves on thinking ahead and anticipating future needs, no matter how remote. I think this attitude stems from the difficulty that programmers have had with maintenance. Maintaining large systems has been so difficult and fraught with problems that many analysts and programmers would rather spend enormous effort at the front end of the systems development cycle, so they don't have to maintain the system ever again. But as history shows, this approach of guessing about the future never works out. No matter how clever we are in thinking ahead, some new, unanticipated requirement comes up to bite us."

    Data Refactoring: Comments by Ken Orr

    Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law.

    Nowhere is this more true than in the software development world. Programers are notoriously optimistic about their capabilities and how easy it will be to add some new feature. "Just" is a very common word in their vocabulary, as in "I just have to change that code a little..." Invariably the problem turns out to be harder than expected, and the "just" turns out to have been unjustified. They just forgot about this or that little complication...

    Not to say that programmers are the only ones in software development who have too rosy a picture of how things are. Their managers - unless enlightened by a few hard knocks - and their clients, often tend to underestimate the issues. Perhaps they can visualise the desired system, and roughly what's going to be needed to realise it. The problem is, the system itself, and the development environment, may introduce complexities and develop a kind of "friction" that gradually makes it harder to move forward.

    It's true that object-oriented programming and the trend towards increasing reusability is helping to ameliorate the situation, but still, it's not quite enough by itself to overcome the problems raised by increasingly ambitious projects. What's needed is some way to strip out everything that slows us down, leaving the essential core plainly visible and amenable to change.

    Enter "eXtreme Programming" (XP), designed to improves the efficiency of software development. This is accomplished by streamlining complexity, delivering top business value early and consistently, and reducing the cost of nearly inevitable changes to the business rules, programming environment, or software design. Many of these practices have been part of conventional wisdom for years, but rethinking their interaction is the value of XP. The Extreme Programming movement has been a subset of the object-oriented (OO) programming community for several years, but has recently attracted more attention, especially with the recent release of Kent Beck's new book Extreme Programming Explained: Embrace Change.

    I was initially attracted to XP because many of the "core practices" have been part of my working methods for many years, but they weren't practices encouraged by the classical methodologies. Such as "Do the simplest thing that could possibly work". On starting a new project, I always wanted to see how quickly and simply I could get anything running that demonstrated the core requirements. Once I had this I felt that I had a foot in the door. Another XP practice I followed was "Refactoring" - keeping code as clean and elegant as possible at all times, by removing redundancies, eliminating unused functionality, and rejuvenating obsolete designs.

    Classically, we are taught "If it ain't broke, don't fix it". XP denies this, on the grounds that software quality is of paramount importance. Let me illustrate with a couple of personal experiences. One time, working with a very close friend on a piece of code, I noticed that she'd coded a segment in 6 lines, which could have been done in 3. She thought I was being picky, but my argument was that if she consistently wrote twice as much code as necessary, then it wouldn't be just those 6 lines of code, but perhaps 6,000, that could have been only 3,000, and that the latter would be far easier to maintain and extend.

    Here's a specific example of bloated code that I've actually seen (in a system for Hubble Space Telescope users): 

    	if	(lookup(key,table) == true)	{

		result	= true;
		}
	else	{
		result	= false;
		}
	return	result;

    This is a particularly telling example because it shows a total lack of understanding of boolean expressions. It should have been written simply as return lookup(key,table). Again, if the author has written all his or her code like this, then somebody is going to have a horrible time changing it.

    Try this little test: how many lines of code do you need to switch between two fixed values each time it is executed? For example, if you need to set x to 3, then 6, then 3 , then 6, ...? Answer

    Classically, programmer productivity was measured by how many lines of code they wrote in, say, a month. If John wrote 6,000 but Jane only wrote 3,000, John was regarded as more productive than Jane. But, suppose the code they wrote achieved the same objectives? Wouldn't you rather have the lesser amount of code? Whenever I'd finished a piece of code, I used to clean it up, usually making it significantly smaller. It used to amuse me to think that I was spending time to decrease my 'productivity' by generally accepted standards!

    Another habit I had was to write tests for my code, before writing the code. This helped clarify the specification, and helped to avoid the temptation to move on to the next fun programming puzzle rather than writing tests for code you knew was just fine... Again, this is an XP practice.

    The following is adapted from Extreme Programming FAQ and other sources.

    The Planning Game
    The XP planning process allows the client to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The client and development team cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
    1. The client comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
    2. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
    3. The client then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
    Small Releases
    XP teams put a simple system into production early, starting with the smallest useful feature set, and update it frequently on a very short cycle. Release early and often, adding a few features each time.
    System Metaphor
    XP teams use an organizing metaphor, with a common "system of names" which provides an easy to remember naming convention, and a common system description that guides development and communication.
    Simple Design
    A system built with XP should be the simplest possible design that gets the job done. The requirements will change at any time, so only do what's needed to meet current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below.
    Continuous Testing
    XP teams focus on validation of the software at all times. Programmers develop software by writing tests first. Before programmers add a feature, they write a test for it. Customers provide acceptance tests that enable them to be certain that the features they need are provided. When the suite runs, the job is done. Tests in XP come in two basic flavors.
    1. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit.
    2. Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
    Refactoring
    XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything by appying the tests.
    Pair Programming

    XP programmers write all production code in pairs, two programmers working together at one machine. Essentially, all code is reviewed as it is written. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone.

    One of the few software engineering practices that enjoys near-universal acceptance (at least in theory) and has been well measured is software inspections (also referred to as reviews or walkthroughs). At their best, inspections are collaborative interactions that speed learning as much as they uncover defects. One of the lesser-known statistics about inspections is that although they are very cost effective in uncovering defects, they are even more effective at preventing defects in the first place through the team's ongoing learning and incorporation of better programming practices.

    Collective Code Ownership
    All the code belongs to all the programmers. No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time. This lets the team go at full speed, because when something needs changing, it can be changed without delay.
    Continuous Integration
    All changes are integrated into the software system at least daily. The tests have to run 100% both before and after integration. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.
    40-Hour Work Week
    Programmers go home on time. Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
    On-site Customer
    An XP project is steered by a dedicated individual, who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. Ideally this is someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project.
    Coding Standards
    For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly. Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.