Professional Documents
Culture Documents
Programming
Outline
Traditional life cycle vs. XP
XP values
XP practices
Pair programming
References
2
Extreme Programming
(XP)
XP does not involve bungee cords!
XP Introduction
3
Successes in industry
4
Embrace change
In traditional software life cycle models, the cost of changing a
program rises exponentially over time
Why would it cost more to make large changes during testing than during
requirements specification?
5
Four Core Values of XP
Communication
XP values
Simplicity
Feedback
Courage
6
Communication
7
Simplicity
9
Courage
10
Twelve XP Practices
Continuous Integration
Metaphor
40-Hours a Week
Simple Design
On-Site Customer
Test-driven
development Coding Standards
Refactoring
11
The Planning Game
Customer comes up with a list of desired features for the system
How is this different from the usual requirements gathering?
XP Practices
Developers estimate how much effort each story will take, and how
much effort the team can produce in a given time interval (iteration)
Project velocity = how many days can be committed to a project
per week
Why is this important to know?
12
Small and simple
Small releases
Start with the smallest useful feature set
XP Practices
Simple design
Always use the simplest possible design that gets the job
done
The requirements will change tomorrow, so only do what's
needed to meet today's requirements (remember, YAGNI)
13
Test-driven development
Test first: before adding a feature, write a test for it!
If code has no automated test case, it is assumed it does not work
When the complete test suite passes 100%, the feature is accepted
XP Practices
14
Pair programming
Two programmers work
together at one machine
navigator critiques it
Research results:
Pair programming increases productivity
Higher quality code (15% fewer defects) in about half the time (58%)
Williams, L., Kessler, R., Cunningham, W., & Jeffries, R. Strengthening the case for
pair programming. IEEE Software, 17(3), July/August 2000
Requires proximity in lab or work environment
15
Pair programming in CS
classes
Experiment at NC State
CS1— programming in Java
Two sections, same instructor, same
exams
XP Practices
Results:
68% of paired students got C or better vs. 45% of solo students
Paired students performed much 16-18 points better on first 2 projects
No difference on third project (perhaps because lower performing solo students had dropped before the third project)
Midterm exam: 65.8 vs. 49.5 Final exam: 74.1 vs. 67.2
Course and instructor evaluations were higher for paired students
16
Pair programming in CS
classes?
Strategies for making it work
Peer evaluation helps motivate students work; perceived fairness
Pair programming in labs alleviates scheduling time for meetings
XP values
Pair programming labs (with role reversals) are noisier than solo labs
17
More XP practices
Refactoring
Refactor out any duplicate code generated in a coding
XP Practices
session
You can do this with confidence that you didn't break
anything because you have the tests
Continuous integration
All changes are integrated into the code base at least daily
Tests have to run 100% both before and after integration
18
More practices
On-site customer
Development team has continuous access to a real live customer, that
is, someone who will actually be using the system, or a proxy
Coding standards
Everyone codes to the same standards
Ideally, you shouldn't be able to tell by looking at it who on the team
has touched a specific piece of code
19
13th XP practice:
Daily standup meeting
Goal: Identify items to be accomplished for the
day and raise issues
• Everyone attends,
including the
customer
• Not a discussion forum
• Take discussions
offline
• Everyone gets to
speak
• 15 minutes
20
Kindergarten lessons
Williams, L. and Kessler, R., “All I Really Need to Know
about Pair Programming I Learned In Kindergarten,”
Communications of the ACM (May 2000)
Share everything. (Collective code ownership)
Play fair. (Pair programming—navigator must not be passive)
Don’t hit people. (Give and receive feedback. Stay on track.)
Clean up your own mess. (Unit testing.)
Wash your hands before you eat. (Wash your hands of
skepticism: buy-in is crucial to pair programming.)
Flush. (Test-driven development, refactoring.)
Take a nap every afternoon. (40-hour week.)
Be aware of wonder. (Ego-less programming, metaphor.)
21
XP practices—a road map
(from www.extremeprogramming.org)
22
XP emphasizes iteration
23
XP emphasizes
communication
24
Test-driven development
25
Discussion?
26
References
Anderson, A., Beattie, Ralph, Beck, Kent et al. Chrysler goes to
“extremes”, Distributed Computing (October 1998), 24-28.
Beck, K., Extreme Programming Explained (Addison Wesley 2000).
Corsaro, A., eXtreme Programming, Powerpoint notes at http://
tao.doc.wustl.edu/~corsaro/resources/talk/XP/xp.ppt.
Katira, N. Williams, L., Wiebe, E., Miller C., Balik, S. and Gehringer, E.,
On understanding compatibility of student pair programmers,
Proceedings of SIGCSE 2004, Norfolk, VA (March 2004), pp. 7-12.
Williams, L., Wiebe, E., Yang., K., Ferzli, M., Miller, C., In support of pair
programming in introductory computer science courses, Journal of
Computer Science Education (September 2002) (
http://collaboration.csc.ncsu.edu/laurie/Papers/PP in
Introductory_CSED.pdf).
Williams, L. and Kessler, R., Experimenting with industry’s “pair-
programming” model in the computer science classroom. Computer
Science Education (March 2001).
Van DeGrift, T. Comparing pair programming and writing: Learning
students’ perceptions and processes, Proceedings of SIGCSE 2004,
Norfolk, VA, pp. 7-12.
http://www.extremeprogramming.org
27