COMPUTING SCIENCE 220
Software Engineering and Human-Computer Interfaces

Extreme Programming

Assumptions

It is commonly assumed (and was taught in this course) that the cost of changing software rises exponentially over time.

If the cost of change curve could be flattened, then other conventional assumptions about the best way to develop software would no longer hold.

There are technologies and practices that make software easier to change later in the development process:

• objects and object databases
• a simple design, with no extra design elements for future-proofing
• automated tests
• lots of practice in refining and modifying the design (refactoring)

A Metaphor

Learning to drive:

Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.

Four Values

• Communication -- XP employs practices that can't be done without communicating.
• Simplicity -- "What is the simplest thing that could possibly work?"
• Feedback -- Concrete feedback is used in several contexts:
  • Programmers write unit tests for all the logic in the system that could possibly break.
  • When customers write new "stories" (simplified use cases), programmers immediately provide concrete feedback in the form of cost/time estimates.
  • Customers and testers write functional tests for all the stories implemented by the system.
  • The development schedule is reviewed frequently, and adjusted as needed.
  • The system is put into production as soon as possible, so programmers get concrete feedback about the quality of their decisions.
• Courage -- It takes courage:
  • to fix an architectural flaw that is discovered late in a project, even though it breaks half the tests that were running.
  • to throw away code that isn't going very well, and to start over from scratch.
  • to spend a day coding each of three design alternatives, then to start over on the most promising design.

The four values support each other. They are embodied in concrete ways in the practices of XP.

Basic Principles

• Rapid feedback -- "get feedback, interpret it, and put what is learned back into the system as quickly as possible."
• Assume simplicity -- "Treat every problem as if it can be solved with ridiculous simplicity." "[T]rust your ability to add complexity in the future when you need it."
• Incremental change -- "Big changes made all at once just don't work."
• Embracing change -- "The best strategy is the one that preserves the most options while actually solving your most pressing problem."
• Quality work -- "Everybody likes doing a good job."

Activities

We need to provide a structure to support the following basic activities:

• Coding
• Testing
• Listening
• Designing

The Twelve Practices

• The Planning Game -- "Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan."

  Business people decide about

  • scope
  • priority
  • composition of releases
  • dates of releases

  Technical people decide about

  • estimates
  • consequences of business decisions
  • process
  • detailed scheduling

• Small releases -- "Put a simple system into production quickly, then release new versions on a very short cycle."
• Metaphor -- "Guide all development with a simple shared story of how the whole system works."
• Simple design -- "The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered."
• Testing -- "Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished."
• Refactoring -- "Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility."
• Pair programming -- "All production code is written with two programmers at one machine."
• Collective ownership -- "Anyone can change any code anywhere in the system at any time."
• Continuous integration -- "Integrate and build the system many times a day, every time a task is completed."
• 40-hour week -- "Work no more than 40 hours a week as a rule. Never work overtime a second week in a row."
• On-site customer -- "Include a real, live user on the team, available full-time to answer questions."
• Coding standards -- "Programmers write all code in accordance with rules emphasizing communication through the code."

"The practices support each other. The weakness of one is covered by the strengths of others."

Managing XP

Some additional principles that relate to managing an XP project:

• Accepted responsibility -- "It is the manager's job to highlight what needs to be done, not to assign work."
• Local adaptation -- XP should be adapted to local conditions, especially to manage the clash between XP culture and the company culture.
• Travel light -- Don't impose a lot of management overhead (long meetings, lengthy reports).
• Honest measurement -- Use metrics "at realistic levels of accuracy".

The manager's tasks and roles:

• Metrics -- Metrics are gathered not to control the project "by the numbers", but as a tool of communication and feedback, "a way of gently and noncoercively communicating the need for change."
  • The ratio between estimated development time and calendar time is the basic metric used in the Planning Game.
  • Project Velocity -- a measure of how much work is getting done: the sum of the estimates of the user stories and tasks that were finished during an iteration.
  • Ideal Engineering Time -- how long it would take to implement a story if that were all a programmer had to do (with no interruptions, meetings, etc.)
  • Big Visible Chart -- update a prominently displayed chart rather than sending metrics to everyone by e-mail.
• Coaching -- guiding the technical execution and evolution of the process; helping everybody else to make good decisions.
• Tracking -- gathering and communicating metrics; running the Planning Game.
• Intervention -- step in and make (unpopular) decisions when needed.

References

Books

This lecture is an outline and summary of the first few chapters of the most important resource on XP:

Extreme Programming Explained: Embrace Change by Kent Beck (Addison Wesley, 2000) QA 76.76 D47 B434

Some other books in the XP series (all from Addison Wesley):

Planning Extreme Programming by Kent Beck and Martin Fowler

Extreme Programming Installed by Ron Jeffries, Ann Anderson, and Chet Hendrickson (Addison-Wesley, c2001) QA 76.76 D47 J44 2001

Extreme Programming Examined by Giancarlo Succi and Michele Marchesi

Extreme Programming Explored by William C. Wake

The essential book on a practice related to XP is:

Refactoring by Martin Fowler (Addison-Wesley, 1999) QA 76.76 R42 F69 1999

Web Resources

Extreme Programming: A gentle introduction.

The Rules and Practices of Extreme Programming.