1. Extreme Programming Theory & XPeriences
Arie van Deursen
31 October 2000
- Achtergrond CWI, SIG, Abn Amro, XP ervaring, XP conferentie
- Vragen naar achtergrond bezoekers:
OO ervaring? Ontwikkelaars? Projectleiders? Management? Testers?
- XP = ontwikkelingsmethodiek.
Kent Beck, reflecteert op eigen software ontwikkeling.
- Software Ontwikkeling:
wat belangrijkste “gewoontes” , “best practices”?
Vb: testen, code review, UML, up fron specs
- XP: zet best practices op max.
- Profiteer van ontwikkelingen in techniek:
OO, design pattern, relational databases, GUI, CBD

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
Eerst vragen:
wat zijn de belangrijkste risico’s?

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. XP Practices The Planning Game Small Releases Metaphor Simple design
Testing
Refactoring
Pair programming
Collective ownership
Continuous integration
40-hour week
On-site customer
Coding standards
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

7. Test First Run all tests and get green bar;
Write (failing) test before 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 Refactoring A change made Refactor:
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. Bad Smells in Code Duplicated Code Long Method Large Class
Say it once!
And only once!
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
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;
Refactor to bring code to simplest state

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!
Vraag: eens of niet?
Implicaties?

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: The Goal:
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: The Pieces:
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: The Moves:
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 Simplicity Feedback Courage
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. XP Basic Principles 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

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.)

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