Extreme Programming Theory & XPeriences

1. Extreme ProgrammingTheory & XPeriences Arie van Deursen 31 October 2000 http://www.cwi.nl/~arie/

2. Software Development Risks What are your most pressing development problems? • Schedule slips • Project canceled • System goes sour / high defect rate • Business misunderstood / changes • False feature rich • Staff turnover

3. XP Project Characteristics • Use of object technology (use of modern language) • Development team size: • 2 to 20 people • Developers take responsibility • Participating customer

4. The Planning Game Small Releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards XP Practices all applied to the extreme

5. Self-Testing Code • Every class also has a TestClass • TestClass methods: • set up fixture • invoke code to be tested • Automatically check results • tear down fixture • Collect test in suites; run them all. All tests must run at 100% at all times

6. JUnit http://www.junit.org

7. Test First • Run all tests and get green bar; • Write (failing) testbefore coding: • if interface is unclear • if implementation might be hard • for every special case (if-then-else) • before dealing with bug report • Modify the code to turn red into green bar

8. Our Testing XPeriences • Test / production code ratio of 1:2 • Writing tests forced us to write smaller methods • Test case = documentation • Having many test cases helps to dare change other people’s code. • Systematic reuse of each other’s tests

9. Refactoring Interactive Transformation Introduce design patterns • Refactoring A change made • to the internal structure of software • to make it easier to understand • and cheaper to modify • without changing its observable behavior • Refactor: • apply series of refactorings

10. Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Speculative Generality Inappropriate Intimacy Comments Switch Statements Data Clumps Data Class Bad Smells in Code Say it once! And only once! Delving into each other’s private parts Need to take some responsibility out of the cave into the centrally heated world of objects

11. Why Refactor? • Improves the Design of Software • Makes software easier to understand • Refactor first to understand unfamiliar code • Small refactoring -> larger ones • “Wiping the dirt off a window, so you can see beyond” • Helps you find bugs • Helps you program faster

12. When should you Refactor? • Three strikes and you refactor • First time: just do it. • Second time something similar: duplicate • Third time something similar: refactor. • Add feature • Fix bug • Review Code

13. Refactoring Process • Modifying code involves: • Test (add if necessary) • Refactor to increase understanding • Test • Add tests for change, modify until it passes; • Test • Refactor to bring code to simplest state • Test

14. Refactoring Catalog • Name • Summary • Motivation • Mechanism • Examples Simple renamings up to major changes to class structure

15. Refactoring XPeriences • Software improvement is explicit part of programming activity • Possible thanks to test suites • Small refactorings on a daily basis • Large refactorings applied incrementally.

16. Simplicity • XP: Have the simplest design that runs the current test suite: • Code + tests communicate everything you want to communicate • The system contains no duplicate code • The system has the fewest possible classes • The system has the fewest possible methods • Achieved by constant refactoring!

17. Design Through Refactoring • Each change includes refactoring • Each refactoring improves/repairs the design • Large refactorings done by need • Each refactoring = mini design-phase • => Death of the big design (phase) • => No separation programmer/architect

18. Design for Tomorrow • Guess at the future. • Tomorrow may never happen • Learn a better way to implement a change before the time you need it • Pay cost of carrying along a more complicated design • Costs of unused generalizations > benefits of used generalizations

19. Design for Today • Trust your ability to change • Rely on tests • Implement changes together • Use modern programming technology • Remove any flexibility that isn’t useful • Design test by test: Repeatedly • Write a test -> implies bit of design; • Design & implement its code • Refactor when necessary

20. Our Design XPeriences • Designs evolve • Re-design = refactoring • Small refactorings done every day • Major refactorings: • Senior programmers involved • Discussed with complete team • Exploration first • Implemented incrementally

21. Pair Programming • All production code is written with two people looking at one machine, with one keyboard and one mouse. • If code review is good, we do it all the time

22. Pair Programming XPeriences • (Initial) resistance • Changing pairs • Discuss design, refactorings, tests • Way to communicate system knowledge • Improves quality (a lot) • Coding is more fun, calmer, and less solitary • More (> 2) productive

23. User Stories • Collect requirements as user stories • Possible to explain, test, and estimate • Prioritize stories in order of business importance • Development: • Estimate effort for stories • Highlight technical risks / consequences

24. Growing a System • Have a running system from day 1. • Integrate stories one by one • Work with small iterations: • Approx. 3 weeks • Split (combine) stories into tasks, estimate • Design, test, build, test • Measure progress, learn to estimate

25. Planning a Release • Release: every 2 - 6 months • Fix date, cost and quality • Determine scope: how many stories can be done following development estimates • Most important user stories first • Feedback / adjustment at every iteration • New / modified stories • Changed estimates

26. The Planning Game • XP Planning: • Dialog between possible and desirable • Set of rules to govern building respectful relationship • Metaphor: Game • The Goal: • Maximize value of software produced by the team

27. Planning Game (cont.) • The Strategy: • Put the most valuable functionality • into production as quickly as possible • with minimal initial investment • addressing risk first • The Pieces: • Cards containing user stories

28. Planning Game (cont.) • The Players: • Business: decides what system must do • Development: build the system • The Moves: • Exploration: what could system do? • Commitment:decide on this release • Steer: Guide actual development, adjust.

29. Our Planning XPeriences • Planning internal product development • Mimicked customer, “invented” stories • Work in small iterations • Always have a running system • Planning customer development • Made planning process “XP-like” • Didn’t force customer into XP game (yet…) • Learning to plan more systematically.

30. XP Values • Communication • Adopt practices that encourage talking & listening • Simplicity • What is the simplest thing that could possibly work? • Feedback • The system tests will tell you; Listen to the code! • Courage • Go at top speed

31. Rapid feedback Assume simplicity Incremental change Embracing change Quality work Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with instincts Accepted responsibility Local adaptation Travel light Honest measurement XP Basic Principles

32. XP Roles • Programmer -- pairing, testing, coding, designing, estimating -- courageous. • Customer -- provide user stories + tests • Tester -- implement functional tests • Tracker -- log progress • Coach -- teach to learn • Consultant -- optional specialist • Big Boss -- confident

33. Adopting XP • Have motivated team • Learn practices one by one • Deceivingly simple • tests, refactoring, pairing, planning • Take sufficient time to learn • Course (spread over year), mentoring • But make sure you try!

34. Further Info • K. Beck -- eXtreme Programming eXplained • M. Fowler -- UML Distilled (2nd Ed.) • www.c2.com/wiki • www.xprogramming.com

35. The Planning Game Small Releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards Summary: XP Practices all applied to the extreme