Extreme Programming: So What?

Extreme Programming:So What?This talk by Ed Gehringer based on notes byRoy W. MillerRoleModel Software, Inc.Copyright 2002 by RoleModel Software, Inc.Why Extreme Programming? Be more valuable than your peers. Be more productive. Make you happier.Copyright 2002 by RoleModel Software, Inc.1

The Real Project Lifecycle DreamPlanCapture requirementsDesign a lot, code a little, testif there’s time Limp to the finishCreate a comprehensive plan, stick to it atall costs, kill change, hope you surviveCopyright 2002 by RoleModel Software, Inc.The Results Junk Late For a lot of moneyData from 2000 CHAOS Report, Standish GroupThe software you wanted at thebeginning, not the endCopyright 2002 by RoleModel Software, Inc.2

The Source: Taylorism Frederick Winslow Taylor,Principles of ScientificManagement (1911) Accepted wisdom by 1950s Software began in 1950s Software “production” industrial production Exercise: Find aninteresting fact aboutTaylorism. Submit here.“[I]n each trade there isalways one method and oneimplement which is quicker andbetter than any of the rest. Andthis one best method and bestimplement can only bediscovered or developedthrough a scientific study andanalysis of all of the methodsand implements in use,together with accurate, minute,motion and time study. “Making software is like a factory – anefficiency optimization problemCopyright 2002 by RoleModel Software, Inc.Software Is DifferentTraditional view Reality Software like industrialproduction Problem always the sameSolution always the sameOptimize processChange is disruptiveIncrease predictabilitySoftware like predicting theweather Problem always differentSolution always differentCan’t optimizeChange is constantCan’t predict accuratelySoftware is emergentCopyright 2002 by RoleModel Software, Inc.3

Growing SoftwareNeed a solution that Allows us not to know Allows us to explore Gives us feedback to direct us Creates the right conditions, lets software emerge Lets us produce the right software at the ENDXP creates the right conditions foremergent softwareCopyright 2002 by RoleModel Software, Inc.XP In a Nutshell 4 core values: Simplicity, Communication, Feedback,Courage 19 practices 1 team 3 roles: Customer, Manager, ProgrammerWhat is the simplest thing we can do andstill make great software?Copyright 2002 by RoleModel Software, Inc.4

The PracticesJoint––––DevelopmentCommon VocabularyIterationsOpen WorkspaceRetrospectivesTest-First DevelopmentPair ProgrammingRefactoringCollective OwnershipContinuous IntegrationJust-In-Time �–StorytellingRelease PlanningAcceptance TestsFrequent Releases–––––Accepted ResponsibilityAir CoverQuarterly ReviewMirrorSustainable PaceXP is about more than programmingCopyright 2002 by RoleModel Software, Inc.Joint PracticesCommon VocabularyFormerly “metaphor” – sharedunderstandingIterationsSteering – frequent, regularcheckpoints so we can get lotsof concrete feedbackOpen WorkspaceEasy to communicate and learnRetrospectivesBeing “Reflective Practitioners”(Donald Schon), learn as we goExercise: Look up one of these practices (your row number mod 4), and findan interesting fact about it. Submit here.Create an environment where “one team”can exist and thriveCopyright 2002 by RoleModel Software, Inc.5

Customer PracticesStorytellingDescribe each system feature ina small chunk that fits in aniterationRelease PlanningTell programmers which featurescome firstCustomer TestsAlso “acceptance tests” or“functional tests” – tellprogrammers when they’re doneFrequent ReleasesGet software to users so theteam can get feedback to steerwithExercise: Look up one of these practices (your row number mod 4), and findan interesting fact about it. Submit here.“Drive” the entire processCopyright 2002 by RoleModel Software, Inc.Management PracticesAccepted ResponsibilitySay what needs to be done, letthe team decide who does it andhowQuarterly ReviewMake sure the team knows whatit needs to; make suremanagement knows what itneeds toAir CoverSoften up the defenses to makeroom for the infantrySustainable PaceHelp people avoid burnoutMirrorPoint out problems, suggest,advise, encourageExercise: Look up one of these practices (your row number mod 5), and findan interesting fact about it. Submit here.Educate, facilitate, stay out of the wayCopyright 2002 by RoleModel Software, Inc.6

Development PracticesTest-First DevelopmentNo code without a failingprogrammer testPair ProgrammingAll code gets two pairs of eyesRefactoringRemove “smells”Collective OwnershipEveryone owns all of the codeContinuous IntegrationIntegrate many times each dayJust-In-Time DesignKeep design simpleCopyright 2002 by RoleModel Software, Inc.Test-First Development Write tests before you write code– http://www.junit.org– ert.html Write just enough code to get each test to passAll about confidenceProgrammer tests tell you when the code “works”Programmer tests must pass 100% all the timeTest anything you need to be sure it worksComplete test coverage, simplest codethat could possibly work, clear intentCopyright 2002 by RoleModel Software, Inc.7

Pair Programming 2 developers, 1 computer, solving problems togetherOne person “drives,” the other “navigates”Not Driver/PassengerNot Pair WatchingPairs should rotateLove your pairContinuous code review, more efficientlearning, lower project riskCopyright 2002 by RoleModel Software, Inc.Refactoring Changing the design of existing code withoutchanging function– http://www.refactoring.com All about speed Refactor when code “smells”––––Methods, classes that are too long.Duplicate code (or “almost” duplicate code).Switch statements (instead of polymorphism).“Struct” classes—getters & setters but little else. Refactor before adding a feature, and afterKeep code simple, build learning inCopyright 2002 by RoleModel Software, Inc.8

Collective Ownership Any developer can change any code anytime Programmer tests and customer tests tell you if youbroke something You break it, you fix itExercise: Is this a good idea? Look up points pro and con. Submit here.Convert “my code” to “our code” to lowerriskCopyright 2002 by RoleModel Software, Inc.Continuous Integration Integrate changes multiple times each dayOne failing Programmer Test no integrationDaily is not enoughNo “Big Bang”Exercise: Is this a good idea? Look up points pro and con. Submit here.Maintain speed and spread risk byintegrating many times per dayCopyright 2002 by RoleModel Software, Inc.9

Just-In-Time Design Only design for what you’re buildingAlways keep the design as simple as possibleSimplicity allows for changeChange is constantExercise: Is this a good idea? Look up points pro and con. Submit here.Simple design: passes all tests, has noduplication, expresses intent, has leastamount of codeCopyright 2002 by RoleModel Software, Inc.All Or Nothing? Some practices can stand alone – Refactoring, TestFirst Development, Pair Programming All is better, some often better than none All doesn’t mean starting all at onceThe closer you get to all, the better offyou areCopyright 2002 by RoleModel Software, Inc.10

So What?XP doesn’t matter – results do XP reflects the true nature of the problem (complex)XP is change-tolerantXP is realisticXP has the potential to facilitate organizationalchangeXP increases likelihood for successCopyright 2002 by RoleModel Software, Inc.Resourceshttp://www.xprogramming.com (Ron Jeffries)http://www.junit.org (JUnit testing framework)Addison Wesley XP Series:Extreme Programming Explained: Embrace Change, BeckExtreme Programming Installed, Jeffries, Hendrickson, AndersonPlanning Extreme Programming, Fowler and BeckExtreme Programming Applied: Playing to Win, Auer and MillerRefactoring, FowlerIBM developerWorks XP Column, starting in August(http://www.ibm.com/developerWorks)Growing Software (working title), Addison Wesley, 2003http://www.roywmiller.comCopyright 2002 by RoleModel Software, Inc.11

–Pair Programming –Refactoring –Collective Ownership –Continuous Integration –Just-In-Time Design Management –Accepted Responsibility –Air Cover –Quarterly Review –Mirror –Sustainable Pace Customer –Storytelling –Release Planning –Acceptance Tests –Frequent Releases XP is about more than programming