This document discusses the principles and practices of Extreme Programming (XP), an agile software development process. It describes XP as an intense, test-centric programming process focused on projects with high rates of change. Key practices include pair programming, test-driven development, planning with user stories and tasks, doing the simplest thing that could work, and refactoring code aggressively. Problems may include short-term "hill-climbing" solutions and risks of fundamental design errors. The document provides additional resources on XP and notes that the day's session will involve practicing XP techniques through pair programming.

1. Steve Loughran
HP Laboratories
steve_loughran@hpl.hp.com
XP Deployed

2. 2004-09-14Page 2
What is XP?
• Intense programming process
• Targeted at projects with high rate of change
• Test-centric, team-centric
• First of the Agile Processes
(as opposed to the rigorous processes)

3. 2004-09-14Page 3
What is XP Not?
• An excuse to save money on computers
• A reason not to design things, when you know that
the design matters.
• A silver bullet
Problems of XP
• Hill-climbing: short term solutions
• Stability of APIs
• Risk of making fundamental design errors

4. 2004-09-14Page 4
Pair Programming
• Two Brains to a keyboard
• Alternate coding, thinking, for maximum velocity
• Second person can
– research things (book, 2nd
laptop)
– design tests
– think about hard problems

5. 2004-09-14Page 5
Test First coding
Because nobody will write tests second.
1. Write tests that fail. These form the specification.
2. Implement the code that causes the tests to work.
3. At this point, you are done, or the tests were
inadequate. Ship or repeat, as appropriate.

6. 2004-09-14Page 6
Planning: user stories and tasks
• User Story == a card describing something of
tangible value to a user
• Engineering Task: a stage in implementing a user
story.
• Engineering Tasks should implement a story, no
less, and no more.
• Sum of task time = time to implement a story. No
less, no more.

7. 2004-09-14Page 7
Write stories, estimate effort, implement

8. 2004-09-14Page 8
Do the simplest thing that could possibly work
• Do not overengineer.
• Take the simplest, most pragmatic solution to every
problem.
• If that is not appropriate, you can return to it later
and fix.
• If you don’t need to return to it, it was appropriate.
Simpler usually means easier to test, less complexity
to go wrong, etc, etc. Performance often turns out
to be less important than correctness.

9. 2004-09-14Page 9
Refactor aggressively
• Don’t be afraid to change things
• Use the refactor menu on your IDE
• Test before and after

10. 2004-09-14Page 10
Further reading
• http://c2.com/cgi/wiki
• Java tools for Extreme Programming
• Extreme Programming with Ant
• XP Explained, XP Installed.

11. 2004-09-14Page 11
Today
• Thank you to Peter for being facilitator and coder!
• Everyone works in pairs
• Two proposals: let's vote
Goal: practise XP, work together, maybe usable
code.