eXtreme Programming

CS2340
Spring 2004
XP References

• Diagrams in this presentation are from

http://www.extremeprogramming.org
• More information about XP can be found at
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
• Extreme Programming Explained, Kent
Beck, Addison-Wesley
• comp.software.extreme-programming

Fall 2004 2
Three Core Contributors

• Ward Cunningham
• Kent Beck
• Ron Jefferies

• Other notables:
• Robert Martin
• Martin Fowler

Fall 2004 3
XP-eXtreme Programming

• Focus on “the simplest thing that could possibly

work.”
• An approach to programming particularly
appropriate for:
• Small team (2-10 programmers)
• “High risk”
• Rapid changing or unstable requirements
• Requires “testability”
• Main foci:
• “Communication, simplicity, feedback, courage”

Fall 2004 4
Kent: “Communication, simplicity,
feedback, courage”

• It’s all about communication

• With users via User Stories and CRC Cards
• With other programmers via Pair Programming
• Simplicity
• We code no feature before it’s time
• Feedback
• From the users
• From the code via Unit Tests
• Courage: It all does work, but it goes against
much of common wisdom

Fall 2004 5
Fall 2004 6
The Overall XP Lifecycle

Fall 2004 7
User Stories

The Customer contacts an XP development group to start a project. An

XP team insists that the Customer sit with their team the whole time
they're developing. An XP project typically has three phases:
• an exploration phase, where the Customer writes stories, the
Programmers estimate them, and the Customer chooses which
stories will be developed;
• an iteration phase, where the Customer writes tests and answers
questions, while the Programmers program; and
• a release phase, where the Programmers install the software, and
the Customer (hopefully) accepts the result.
The Customer in XP has frequent opportunities to change the team's
direction if circumstances change. Because testing is so prominent,
the Customer is aware of the project's true status much earlier in
the cycle.

Fall 2004 8
User Stories

• Basis for:
• Requirements
• Test Cases
• Project Plan
• Estimate by User Story
• Velocity for overall tracking
• Workload distribution through “sign-up”

Fall 2004 9
Daily Standup Meeting

• Communication among the entire team is the purpose of

the stand up meeting.
• A stand up meeting every morning is used to
communicate problems, solutions, and promote team
focus.
• Everyone stands up in a circle to avoid long discussions.
• It is more efficient to have one short meeting that every one is
required to attend than many meetings with a few developers
each.
• With limited attendance most meetings can take place
spontaneously in front of a computer, where code can
be browsed and ideas actually tried out.

Fall 2004 10
Unit Tests

• A unit test is written BEFORE THE CODE

IS WRITTEN for each piece of the
system.
• When you create your tests first, before the code, you will find it
much easier and faster to create your code.
• The combined time it takes to create a unit test and create some
code to make it pass is about the same as just coding it up straight
away.
• But, if you already have the unit tests you don't need to create them
after the code, saving you some time now and lots later.
• Eases regression testing
• JUnit (for Java), SUnit (for Smalltalk), CppUnit (for C++) allow for
running all unit tests.
• When a bug is found, a new unit test is written to catch that bug in the
future

Fall 2004 11
 SUnit

Fall 2004 12
Pair Programming

• Pair programming increases software quality without impacting time

to deliver.
• All code to be included in a production release is created by two
people working together at a single computer.
• Any code written by an individual must be thrown out
• It is counter intuitive, but 2 people working at a single computer
will add as much functionality as two working separately except
that it will be much higher in quality. With increased quality
comes big savings later in the project.
• The best way to pair program is to just sit side by side in front of the
monitor. Slide the key board and mouse back and forth.
• One person types and thinks tactically about the method being
created, while other thinks strategically about how that method
fits into the class.

Fall 2004 13
Does Pair Programming work?

• Laurie Williams’ Utah dissertation

• Two classes, one paired—one traditional
• Paired students had lower performance at
first
• By end of class, paired students had:
• More “function points” completed
• Fewer bugs
• In less time!
• Other positive results by Williams and
others in recent years
Fall 2004 14
Part of the goal is Learning

• From WikiWikiWeb:
• Pair up your people.
• When applicable, each pair should have a relatively
experienced and a relatively inexperienced person.
• For work being done at a computer, put the relatively
inexperienced person at the keyboard, so everything
the experienced person says has to flow through the
novice to the computer.
• The point is not for the guru to dictate to the
greenhorn; on the contrary, putting the novice at the
keyboard is meant to keep him or her more in the
loop.
Fall 2004 15
Integrate Constantly

• Developers should be integrating and releasing code

into the code repository every few hours, whenever
possible.
• In any case never hold onto changes for more than a day.
• Continuous integration often avoids diverging or
fragmented development efforts, where developers are
not communicating with each other about what can be
re-used, or what could be shared.
• Everyone needs to work with the latest version.
• Changes should not be made to obsolete code causing
integration head aches.
• Use Unit Tests to facilitate Integration

Fall 2004 16
40 Hour Work Weeks

• “You can’t make a pregnancy take only three

months by putting three mothers on it.” — Fred
Brooks
• Overtime is not the solution to bad development
efforts
• XP Rule: “No more than two overtime weeks in
a row”
• Exhausted developers are not efficient
• Defect reduction strategy

Fall 2004 17
Refactor Mercilessly

• We computer programmers hold onto our software

designs long after they have become unwieldy.
• We continue to use and reuse code that is no longer
maintainable because it still works in some way and we are afraid
to modify it.
• But is it really cost effective to do so?
• Extreme Programming (XP) takes the stance that it is not.
• When we remove redundancy, eliminate unused functionality,
and rejuvenate obsolete designs we are refactoring.
• Refactoring throughout the entire project life cycle saves time
and increases quality.

Fall 2004 18
Refactor Mercilessly (cont.)

• Refactor mercilessly to keep the design simple

• Avoid needless clutter and complexity.
• Keep your code clean and concise
• It will be easier to understand, modify, and extend.
• Make sure everything is expressed once and only once.
• In the end it takes less time to produce a system that is well
groomed.

Fall 2004 19
Avoid new functionality
• Keep the system uncluttered with extra stuff you guess will be used
later.
• Only 10% of that extra stuff will ever get used, so you are
wasting 90% of your time.
• We are all tempted to add functionality now rather than later
because we see exactly how to add it or because it would make the
system so much better.
• It seems like it would be faster to add it now.
• But we need to constantly remind ourselves that we are not
going to actually need it.
• Extra functionality will always slow us down and squander our
resources.
• Turn a blind eye towards future requirements and extra flexibility.
• Concentrate on what is scheduled for today only

Fall 2004 20
One of Four Hats

• Kent Beck:
• When you are coding you should be wearing only one of
four different hats.
• Refactoring code, but only changing the interface
• Interface = method names & parameters
• Refactoring code, but only changing the implementation
• Adding new functionality, but only changing the interface
• Adding new functionality, but only changing the implementation.

Fall 2004 21
Example of Refactoring

(Kent Beck on the Refactoring Browser in Smalltalk):

If I notice
...
area := aRectangle right - aRectangle left *
(aRectangle bottom - aRectangle top).
....
I select the statement to the right of the assignment and "extract method",
naming the new method areaOf:. Now I have:
...
area := self areaOf: aRectangle.
...
areaOf: aRectangle
^aRectangle right - aRectangle left * (aRectangle
bottom - aRectangle top)

Fall 2004 22
Example (cont’d)

Now I notice that aRectangle cares a lot more about this message than I do:
area := self areaOf: aRectangle.
...
areaOf: aRectangle
^aRectangle area
Rectangle>>area
^self right - self left * (self bottom - self top)
Now, areaOf: isn't doing me much good:
...
area := aRectangle area.
...
Rectangle>>area
^self right - self left * (self bottom - self top)

Fall 2004 23
Key Idea

• We only do one refactoring a time

• We follow standard refactorings
• Therefore:
• Design is improved
• We verify each change with our unit tests

Fall 2004 24
 XP is against “Big Design Up Front”

• The Code is the Design

• “When the original phases of software development were laid down, they were
just plain wrong. Requirements, Design, Implementation, and Test are not
what we think they are. Design is not something that you do only before you
code. Implementation is not the act of coding. We can see this if we look
realistically at what they are in other engineering disciplines.”
• "The final goal of any engineering activity is to create some kind of
documentation.”
• “After reviewing the software development lifecycle today, it appears
that the only software documentation that actually seems to satisfy the
criteria of an engineering design are the source code listings. “
• XP is often accused of not believing in comments. That’s not exactly true.
• They do believe heavily in “Self-documenting code”
• But they also believe “The position of the article was not that source code
makes all other documentation obsolete, it is simply that the act of
programming is designing.”

Fall 2004 25
Ward Cunningham On Comments

• We comment methods only after doing everything

possible to make the method not need a comment.
• We prefer to clarify the code directly over putting in an
explanation of what the code could say it if were better
done.
• We have written "literate programs", c.f. Don Knuth, and no one
has used them. Too bad, really, they were cool.

Fall 2004 26
Can this really work?

• There are several Fortune 500 companies that are now

using XP, including Ford, Daimler-Chrysler, and First
Union.
• But it only works ALL TOGETHER. “Almost XP is like
being Almost Alive or Almost Solvent.”
• The emphasis on readable code (even without comments)
works because Pair Programming ensures readable code
• The integrating constantly is made possible by the Unit Tests
• The lack of up-front design effort works because the User is on-
site, the user stories drive the effort, and there’s a high degree
of communication among the team members, and refactoring
continually improves the existing code base

Fall 2004 27
The Overall XP Lifecycle

Fall 2004 28
XP Path

Fall 2004 29
XP Development

Fall 2004 30
XP Collective Code Ownership

Fall 2004 31
Lessons Learned

Fall 2004 32
XP in Perspective

• People tend to love XP or ridicule it

• “If you don’t have a specification, your
program can’t be wrong!”
• In reality, it’s not a binary choice. XP is at
one extreme end of the process spectrum.
• There is much interest these days in so-
called “agile methodologies” which
generally are much closer to XP than to
traditional “heavyweight” approaches.

Fall 2004 33