ICS 121: Extreme Programming

XP is a set of key practices that suggest a software development process.
Key concept: Embrace change. Rather than avoid changes, try to reduce the cost of making changes.
Key concept: Defer costs. Rather than face every problem up front, try to start with a small subset and incrementally plan and carry out improvements.

User story: A short, concrete paragraph about how a user might use one feature of the system.
Test case: Programmatic unit test case. Each test case is very small and would take only an hour or less to write.
Iteration: The work it takes to implement a few user stories. Usually 1-4 weeks.
Release: Several iterations happen lead up to one release. The release produces an externally visible verison of the software. A release can take a few months.

Don't plan too far ahead
- Try to steer the project toward success, one iteration at a time
- Lots of things change, so planning too far ahead is unreliable
- Realize that you will change things later no matter what
The Planning Game
- Record user stories and other development tasks on index cards
- Have a customer (or customer representative) on the team
- Quickly estimate and prioritize user stories
- Negotiate a set of user stories for the next release
Small releases
- Build the smallest, simplest system possible
- Then make a long series of small upgrades, each of which also works
Simple design
- Just do the simplest thing that will get you through this milestone
- Eliminate duplication in the design
- Don't over engineer, solve problems only when they occur
Test-first
- Write a simple, automated test and prove that it fails
- Then, implement the feature and prove that it passes the test
- Rerun tests frequently to find defects and measure progress
Refactoring
- Use tools that make it easy to make design changes as you go
Pair programming
- Two people at the keyboard
- One codes, one thinks about the design and catches errors
Collective code ownership
- Any developer can change any code any time
- Everyone codes to the same stylistic standards
- Automated tests catch any errors that are introduced
Continuous integration
- Merge changes from different developers very frequently
40-hour work week
- It is better to be awake and alert

XP Workers:
- Programmer
- Tester
- Customer
- Coach: Technical mentoring, long-term sylistic goals
- Tracker: track progress toward short-term goals
Steps within each iteration:
- Customer picks user stories with highest priority
- Stories are split into developer tasks
- Develop test cases for each task
- Implement each task and evolve the design as needed
Otherwise, there is not a lot of guidance

XP is better than _no_ process at all.
XP is closest to build-and-fix process model because planning and doing are both incremental with the same duration.
Certain practices of XP are good:
- User stories are a quick and easy way to get started capturing user needs
- Continuous integration, frequent iterations and regression tests
- Joint code ownership, shared coding style
- Tracking of issues
- Pair programming can be nice sometimes
Other practices of XP are not good:
- Short-sighted planning is wasteful
- Refactoring is not as cool as it seems
- Tests are no substitute for written requirements
- Requires a lot of access to customer
- Code is the central artifact, there are few formal requirements or design documents. That means less effort so long as all developers remember the history of decision-making, but it makes it very hard for new developers to join the project later.