eXtreme Programming

1
eXtreme Programming

• CS2340
• Spring 2004

2
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

3
Three Core Contributors

• Ward Cunningham
• Kent Beck
• Ron Jefferies
• Other notables
• Robert Martin
• Martin Fowler

4
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

5
Kent Communication, simplicity, feedback,
courage

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

6
(No Transcript)
7
The Overall XP Lifecycle
8
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.

9
User Stories

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

10
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.

11
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

12
SUnit
13
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.

14
Does Pair Programming work?

• Laurie Williams Utah dissertation
• Two classes, one pairedone 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

15
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.

16
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

17
40 Hour Work Weeks

• You cant 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

18
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.

19
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.

20
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

21
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.

22
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)

23
Example (contd)

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

24
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

25
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.
  Thats 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.

26
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.

27
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 theres a high degree of
  communication among the team members, and
  refactoring continually improves the existing
  code base

28
The Overall XP Lifecycle
29
XP Path
30
XP Development
31
XP Collective Code Ownership
32
Lessons Learned
33
XP in Perspective

• People tend to love XP or ridicule it
• If you dont have a specification, your program
  cant be wrong!
• In reality, its 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.