The 90s had seen the great promise of object technologieslaunchambitious projects that in many cases ended in failure. Objectsthemselves, while conferring  numerous advantages of reuse, werenot the panaceathat manyhad hoped they would be. Fluid ,rapidly-changing requirementsdemanded  shorter lifecycles, and did not gowell with moretraditional  methods of development, which usually requiredextensive design upfront  and  penalized later design changes withhigher   costs ormissed   deadlines.

The Chrysler Comprehensive Compensation project was startedinordertodetermine the best way to use object technologies,usingthe pay rollsystems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the persistence layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuningonthesystem,buthis role expanded as he noted several issuestheywerehavingwiththeirdevelopment process. He took this opportunitytoproposeandimplement somechanges in their practices based onhiswork withhisfrequentcollaborator, Ward Cunningham.

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like

testing and reviews. The second time there was a lot moreontheline.I thought, "Damn the torpedoes, at least thiswillmake a

good article," [and] asked the team to crank up all theknobs to 10 on the things I thought were essential and leave out

everything else. —[Kent Beck (http://www.informit.com/articles/article.asp?p=20972&rl=1)]

Beck invited Ron Jeffriestotheprojecttohelp develop and refine these methods. Jeffriesthereafteracted as akindof coach to instill the practices ashabitsin the C3team.

Information about the principles and practices behind XP was disseminated to the wider world through discussions on theoriginal WikiWiki, Cunningham's Portland Pattern Repository.Variouscontributorsdissectedand expanded upon the ideas,somebecoming ferventadvocates,othersbecoming critics, and yet otherspicking out ideas(see agile software development).

[edit]

Beck edited a series of books on XP, beginning with his own ExtremeProgramming Explained,spreadinghisideasto a much larger yet very receptive audience.Authors intheserieswentthrough various aspects attending XP and itspractices,evena bookcritical of the practices.

XP created quite a buzz in the late nineties andearlytwothousands,seeing adoption in a number ofdifferentmilieusandenvironmentsradically different from its origins.

The high discipline required by the original practicesoftenwentbythewayside, causing certain practices to be deprecatedorleftundoneonindividual sites. Agile development practices havenotstoodstill,and XPis still evolving, assimilating morelessonsfromexperiences inthe field.In the second edition of Extreme Programming Explained, Beck added more values andpractices, and differentiated between primary and corollary practices.

The main aim of XP is to lower the cost of change. In traditional system development methods (like SDM)therequirementsforthesystem are determined at thebeginning of thedevelopment projectandoftenfixed from that pointon. This means thatthe cost ofchangingtherequirements ata later stage in theproject—not unthinkablein arapidlychangingbusiness—will be veryhigh. This conceptisillustratedby thegraph below.

XP sets out to lower the cost of changebyintroducingbasicvalues,principles and practices. By applyingXP,asystemdevelopmentproject should be more flexible withrespecttochanges.The graph belowillustrates the intent to hem inthecostofchange.

The core practices of eXtreme Programming, as described in the first edition of Extreme programming explained can begrouped into four areas (12 practices) as follows:

Fine scale feedback

	Test driven development
	Planning game
	Whole team (original name: Onsite customer)
	Pair programming

Continuous process rather than batch

	Continuous Integration
	Design Improvement (original name: Refactor)
	Small Releases

Shared understanding

	Simple design
	System metaphor
	Collective code ownership
	Coding standard or Coding conventions

Programmer welfare

Sustainable pace (original name: Forty hour week)

In the second edition of Extreme programming explained a set of corollary practices are listed in addition to theprimary practices.

The core practices are derived from generally accepted best practices, and are taken to extremes:

	Interaction between developers and customersisgood.Therefore,an XP team issupposed to have a customer onsite,whospecifies andprioritizes work for the team, and who can answerquestions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
	If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
	Simple code is more likely to work.Therefore,extremeprogrammersonly write code to meet actual needs at thepresenttimein aproject,and go to some lengths to reduce complexity and duplication in their code.
	If simple code is good, re-write code when it becomes complex.
	Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
	Testingcodeisgood.Therefore, in XP, tests are writtenbefore the code iswritten.Thecode isconsidered complete when it passes the tests (butthenitneedsrefactoring to removecomplexity). The systemisperiodically,orimmediately tested using all pre-existingautomatedtests to assurethatit works.See test-driven development.

It used to be thought that Extreme Programming could onlyworkinsmallteams of fewer than 12 persons. However, XPhasbeenusedsuccessfully onteams of over a hundred developers. It isnotthat XPdoesn't scale, justthat few people have tried toscaleit,andproponents of XP refuse tospeculate on this facet of the process.

Extreme Programming initially recognized just four values but a new value was added in the second edition of Extremeprogramming explained. The five values are:

	Communication
	Simplicity
	Feedback
	Courage
	Respect (the latest value)

A fundamental task of building software systemsiscommunicatingsystemrequirements to the developers of thesystem.Informalsoftwaredevelopment methodologies, this taskisaccomplishedthroughdocumentation.

Extreme Programming techniques can be viewed asmethodsforrapidlybuilding and disseminating institutionalknowledgeamongmembersof adevelopment team. The goal is to give alldevelopers ashared viewofthe system which matches the view held bytheusers of thesystem.Tothis end, Extreme Programming favorssimpledesigns,metaphor,collaboration of users andprogrammers,frequentverbalcommunicationand feedback.

eXtreme Programming encourages starting with the simplest solution and refactoringtobetterones.Thedifference between this approachandmoreconventionalsystemdevelopmentmethods is the focus is ondesigningand coding forthe needsof todayinstead of those of tomorrow,next weekor nextmonth.Proponentsof XP acknowledge the disadvantage thatthiscansometimesentail moreeffort tomorrow to change thesystem;theirclaimis that this is morethan compensated for by theadvantageofnotinvesting in possible futurerequirements that maychangebeforetheybecome relevant. Coding anddesigning foruncertainfuturerequirementsimplies the risk of spendingresourcesonsomethingthat might not beneeded. Related to thepreviousvalue,"communication",simplicity indesign and codingshouldimprove the(quality of)communication. Asimple design withsimplecode can beeasily understoodby everyprogrammer in theteam.

Within eXtreme Programming, feedback is related to different dimensions of the system development:

	Feedback from the system: by writing unit teststheprogrammershavedirect feedback from of the state ofthesystemafterimplementingchanges.
	Feedback from the customer: The functional testsarewrittenbythecustomer and the testers. They will getconcretefeedbackaboutthecurrent state of their system. This review isplannedonce ineverytwoor three weeks so the customer can easilysteerthedevelopment.
	Feedback from the team: When customers come upwithnewrequirementsin the planning game the team directlygivesanestimationof the timethat it will take to implement.

Feedback is closely related communication and simplicity.Flawsinthesystem are easily communicated by writing a unittestthatprovesacertain piece of code will break. The direct feedbackfromthesystemtells programmers to recode this part. Acustomer is abletotestthesystem periodically according to thefunctionalrequirements(UserStories). To quote Kent Beck, Optimism is an occupational hazard of programming, feedback is thetreatment.

The Extreme Programming doctrine of "Courage insystemdevelopment"canbe best explained by a couple of practices. Oneisthecommandmenttoalways design and code for today and not fortomorrow.This is aneffortto avoid getting bogged down in designandrequiring alot ofeffort toimplement anything else. Courage enablesdevelopers tofeelcomfortablewith refactoringtheircodewhennecessary. This means reviewing the existingsystemandmodifying itsothat future changes can be implemented moreeasily.Another exampleofcourage is knowing when to throw codeaway.Everyprogrammerhasexperienced getting stuck on a complex problem intheirown designandcode after working on it allday, then coming backthenext day withaclear and fresh view and rapidly solving the probleminhalf an hour.

[edit]

[edit]

The principles that form the basis of XP are based onthevaluesjustdescribed and are intended to foster decisionsinasystemdevelopmentproject. The principles are intended to bemoreconcretethan the valuesand more easily translated toguidance inapracticalsituation.

Feedback is most useful if it is done rapidly. Thetimebetweenanaction and its feedback is critical to learningandmakingchanges.IneXtreme Programming, unlike traditionalsystemdevelopmentmethods,contact with the customer occurs insmalliterations.Thecustomer hasclear insight into the system that isbeing developed.Heor she cangive feedback on the progressand steer thedevelopmentwhereis needed.

Unit tests also contribute to the rapidfeedbackprinciple.Whenwriting code, the unit test provides directfeedback astohowthesystem reacts to the changes one has made. If,forinstance,thechanges affect a part of the system that is not inthescopeoftheprogrammer who made them, that programmer will notnoticetheflaw.There is a large chance that this bug willappear whenthesystemis inproduction.

Assuming simplicity is about treating every problem as itcanbesolved"eXtremely simply". Traditional system developmentmethodssaytoplan forthe future and to code for reusability.Extremeprogrammingrejects theseideas.

The advocates of eXtreme Programming say that Rome wasn'tbuiltinaday: making big changes at once doesnotwork.eXtremeProgrammingapplies incremental changes: for example,asystem inmight have smallreleases every three weeks. By makinglotsoflittlesteps the customerhas more control over the developmentprocessand thesystem that isbeing developed.

It is always certain that there will be uncertainty.Theprincipleofembracing change is about not working againstchangesbutembracethem.For instance, if at one of the iterative meetingsitappears thatthecustomer's requirements havechangeddramatically,programmers aretoembrace this and plan the newrequirements for thenext iteration.

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

The advocates of XP argue that the only truly importantproductofthesystem development process is code (a concept towhichtheygiveasomewhat broader definition than might be givenbyothers).Withoutcoding you have nothing.

Coding can be drawing diagrams that will generatecode,scriptingaweb-based system or programming an object-orientedC#programthatneedsto be compiled.

Coding can also be used to figure out themostsuitablesolution.Forinstance, XP would advocate thatfacedwithseveralalternatives for aprogramming problem, one shouldsimplycodeallsolutions and determinewith automated tests (discussedinthenextsection) what solution ismost suitable.

Coding can also help to communicatethoughtsaboutprogrammingproblems. A programmer dealing withacomplexprogrammingproblem andfinding it hard to explain the solutiontofellowprogrammers mightcode it and use the code to demonstratewhatheor shemeans. Code, saythe exponents of this position, is alwaysclearandconcise and cannotbe interpreted in more than oneway.Otherprogrammerscan give feedbackon this code by also coding theirthoughts.

One cannot be certain of anything unless one has testedit.Testingisnot a perceived, primary need for the customer. Alotofsoftwareisshipped without proper testing and still works (moreorless).Insoftware development, XP says this means thatone cannotbecertainthata function works unless one tests it. This raisesthequestionofdefining what one can be uncertainabout.

You can be uncertain whether what you coded is what youmeant.Totestthis uncertainty, XP uses Unit Tests. Theseareautomatedteststhat testthe code. The programmer will try write asmany tests heorshe can thinkof that might break the codehe or she iswriting; ifalltests runsuccessfully then the coding is complete.

You can be uncertain whether what you meant is whatyoushouldhavemeant. To test this uncertainty, XP usesacceptancetestsbased ontherequirements given by the customer in theexplorationphase ofreleaseplanning.

Programmers don't necessarily know anything about thebusinesssideofthe system development. The function of the systemisdeterminedbythebusiness side. For the programmers to find whatthefunctionalityof thesystem should be, they have to listento business.

Programmers have to listen "in the large": they have tolistenwhatthecustomer needs. Also, they have to try tounderstandthebusinessproblem,and to give the customer feedback abouthis or herproblem, toimprove thecustomer's own understanding ofhis orherproblem.

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

From the point of view of simplicity, one couldsaythatsystemdevelopment doesn't need more than coding,testingandlistening.Ifthose activities are performed well, the resultshouldalways beasystem that works. In practice, that will notwork. Onecancome afarway without designing but at a given time one willgetstuck.Thesystem becomes too complex and thedependencies withinthesystemceaseto be clear.

One can avoid this by creating a design structurethatorganizesthelogic in the system. Good design will avoidlotsofdependencieswithina system; this means that changing one part ofthesystem willnotaffect other parts of the system.

The main planning process within eXtreme Programmingiscalledtheplanning game. This section will explain thisprocessbyusingprocessmodels.

The planning process is divided into two parts:

Release Planning: This is focused on determiningwhatrequirementsareincluded in which release and when it’s goingtobedelivered.Thecustomers and developers are both part ofthis.ReleasePlanningconsists of three phases:Exploration Phase: Inthisphase thecustomerwill give all his requirements for the system.Thesewill bewrittendown onuser story cards.Commitment Phase: Withinthecommitmentphasebusiness and development will commit themselvestothefunctionalitythat willbe included and the date ofthenextrelease.Steering Phase:In the steering phase the plan canbeadjusted,new requirements can beadded and or existingrequirementscanbe changedor removed.

Iteration Planning: This plans the activities andtasksofthedevelopers. In this process the customerisnotinvolved.IterationPlanning also consists ofthreephases:ExplorationPhase: Within thisphase the requirement willbetranslated to differenttasks. The tasksare recordedontaskcards.Commitment Phase: The taskswill be assignedto theprogrammersand the time it takes to completewill beestimated.SteeringPhase: Thetasks are performed and the endtheresult is matched with theoriginaluser story.

This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.

	Get Requirement from Customer: Business has comewithaproblem;during a meeting, development will try todefinethisproblemand getrequirements.
	Write a Story: Based on the business problem, a storyhastobewritten. This is done by business, where they point outwhattheywantapart of the system to do. It is important thatdevelopmenthasnoinfluence on this story for so far thefunctionality.Thestoryiswritten on a so called user story card.
	Split a Story: If development isn't able to estimatethestory(nextitem), it needs to be split up and written again.Again,thismaynotinfluence the business requirements.
	Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.

When business cannot come up with any more requirements, one proceeds to the commitment phase.

This phase involves the determination of costs, benefits, and schedule impact. It has four components:

	Sort by Value: Business sorts the user stories by business value.
	Sort by Risk: Development sorts the stories by risk.
	Set Velocity: Development determines at what speed they can perform the project.
	Choose scope: The user stories that will be finishedinthenextrelease will be picked. Based on the user storiesthereleasedateisdetermined.

The business side sorts the user stories by business value. They will arrange them into three piles:

	Critical: stories without which the system cannot function or has no meaning.
	Significant Business Value: Non-critical user stories that have significant business value.
	Nice to have: User stories that do not havesignificantbusinessvalue; an example can be an improvement inusabilityorpresentation.

The developers sort the user stories by risk. Theyalsocategorizeintothree piles: low, medium and high risk userstories.Thefollowingis anexample of an approach to this:

Determine Risk Index: Give each user story an index from 0to2oneach of the following factors:Completeness (do we know allofthestorydetails?)Complete (0)Incomplete (1)Unknown (2)Volatility(isitlikelyto change?)low (0)medium (1)high (2)Complexity (how hardisittobuild?)simple (0)standard (1)complex (2)

All indexes for a user story are added, assigning the user stories a risk index of low (0–1), medium (2–4), orhigh (5–6).

Within the steering phase the programmersandbusinesspeoplecan"steer" the process. That is to say,theycanmakechanges.Individual user stories, or relativeprioritiesofdifferentuserstories, might change; estimates might provewrong.Thisisthechance to adjust the plan accordingly.

[edit]

The exploration phase of the iteration planning is about creating tasks and estimating their implementation time.

	Gather User Stories: Gather and write all user stories for the next release
	Combine/Split task: If the programmer cannot estimatethetaskbecauseit is too big or too small, the programmer willneedtocombineor splitthe task.
	Estimate task: Estimate the time it will take to implement the task.

Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different userstories.

	A programmer accepts a task: Each programmer picks a task for which he or she takes responsibility.
	Programmer estimates the task: Because theprogrammerisnowresponsible for the task, he or she shouldgivetheeventualestimationof the task.
	Set load factor: The load factor represents theidealamountofhands-on development time per programmerwithinoneiteration.Forexample, in a 40-hour week, with 5 hoursdedicated tomeetings,thiswould be no more than 35 hours.
	Balancing: When all programmers within the teamhavebeenassignedtasks, a comparison is made between the estimatedtimeofthetasks andthe load factor. Then the tasks are balanced outamongtheprogrammers.If a programmer is overcommitted,otherprogrammersmusttake over someof his or her tasks and vice versa.

The implementation of the tasks is done during the steering phase of the iteration planning.

	Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
	Find a Partner: The programmer will implement thistaskalongwithanother programmer. This is further discussedinthepracticePairProgramming.
	Design the task: If needed, the programmers will design the functionality of the task.
	Write unit test: Before the programmers startcodingthefunctionalitythey first write automated tests.Thisisfurtherdiscussed in the practiceUnit Testing.
	Write code: The programmers start to code.
	Run test: The unit tests are run to test the code.
	Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.

Pair Programming means that all code is producedbytwopeopleprogramming on one task on one workstation.Oneprogrammerhascontrolover the workstation and is thinking mostlyaboutthe codingin detail.The other programmer is more focused onthebigpicture, andiscontinually reviewing the code that is beingproducedby thefirstprogrammer.

The pairs are not fixed: it's even recommendedthatprogrammerstrytomix as much as possible, so that everyoneknowswhateveryone isdoing,and everybody can become familiar withthewholesystem. Thisway, pairprogramming also canenhanceteam-widecommunication. (Thisalso goeshand-in-hand with theconceptofCollective Ownership).

Collective ownership means that everybody is responsibleforallthecode; this, in turn, means that everybody is allowedtochangeanypartof the code. Pair programming contributes to thispractice:byworkingin different pairs, all the programmersget to see allthepartsof thecode. A major advantage claimed for collective ownershipisthatitspeeds up the developmentprocess, because if an erroroccursinthecode any programmer may fix it.

By giving every programmer the right to change the code,thereisriskof errors being introduced by programmers who thinktheyknowwhattheyare doing, but do not foresee certain dependencies.Wellenoughdefinedunit tests address this problem:ifunforeseendependenciescreate errors,then when unit tests are run,they will showfailures.

Within XP, the "customer" is not the one who pays the bill,buttheonewho really uses the system. XP says that the customershouldbeathand atall times and available for questions. For instance,theteamdeveloping afinancial administration systemshould includeafinancialadministrator.

Unit tests are automated tests that test the functionalityofpiecesofthe code (e.g. classes, methods). Within XP, unittestsarewrittenbeforethe eventual code is coded. This approach isintendedtostimulate theprogrammer to think aboutconditions in whichhis orhercode could fail.XP says that the programmer is finished withacertainpiece of code whenhe orshe cannot come up with anyfurtherconditionon which the code mayfail.

Because XP doctrine advocates programming only whatisneededtoday,and implementing it as simply as possible, attimesthismayresult in asystem that is stuck. One of the symptoms ofthis istheneed for dual(or multiple) maintenance:functionalchangesstartrequiring changes tomultiple copies of the same(or similar)code.Another symptom is thatchanges in one part ofthe codeaffect lotsofother parts. XP doctrinesays that when this occurs, thesystemistelling you to refactor yourcode bychanging the architecture,makingitsimpler and more generic.See also refactoring.

Extreme Programming also has its share of controversial aspects:

	Detailed specifications are not created or preserved.
	Programmers are required to work in pairs - not all software developers expect to be asked to work this way.
	There is no BigDesign Up Front. Most of the design activitytakesplaceonthe fly and incrementally, starting with "thesimplestthingthatcouldpossibly work" and adding complexity only whenit'srequiredbyfailing tests. This could result in morere-designeffortthanonlyre-designing when requirements change.
	A customer representative is attached to theproject. This role can become a single-point-of-failure for the project and somepeople have found it to be a source of stress.

In 2003, Matt Stephens andDoug RosenbergpublishedabookunderBeck'sXP series imprint called "ExtremeProgrammingRefactored:The CaseAgainstXP" which questioned the valueofthe XP process andsuggestedways inwhich it could be improved(i.e.refactored). Thistriggered alengthlydebate in articles,internetnewsgroups and web-sitechat areas.The coreargument of thebook isthat XP's practices areinterdependentbut thatfewpracticalorganisations are willing/able toadopt allthepractices;therefore theentire process fails. The bookalsomakesothercriticisms and it drawsa likeness of XP's"collectiveownership"model tosocialism (the authors appear to regard this as undesirable).

Certain aspects of XP have changed since the bookwaspublished,inparticular XP now accomodates modifications tothepracticesas longasthe required objectives are still met. Italsousesincreasinglygeneric terms for processes. Some arguethatthesechangesinvalidateprevious criticisms; others claim that thisissimplywatering theprocess down.

Recently, authors have attempted to reconcile XP with the older methods that XP sought to replace (such as the waterfall method) in order to offer a unified method. See http://www.lux-seattle.com/resources/whitepapers/waterfall.htm for an example.