eXtreme Programming

eXtreme Programming

CS2340Spring 2004

Fall 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

Fall 2004 3

Three Core Contributors

• Ward Cunningham

• Kent Beck

• Ron Jefferies

• Other notables:• Robert Martin• Martin Fowler

Fall 2004 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”

Fall 2004 5

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 6

Fall 2004 7

The Overall XP Lifecycle

Fall 2004 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.

Fall 2004 9

User Stories

• Basis for:• Requirements• Test Cases• Project Plan

• Estimate by User Story• Velocity for overall tracking

• Workload distribution through “sign-up”

Fall 2004 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.

Fall 2004 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

Fall 2004 12

SUnit

Fall 2004 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.

Fall 2004 14

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

Fall 2004 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

Fall 2004 17

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

Fall 2004 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.

Fall 2004 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

Fall 2004 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.

Fall 2004 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)

Fall 2004 23

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

Fall 2004 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. 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 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.

Fall 2004 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 there’s a high degree of communication among the team members, and refactoring continually improves the existing code base

Fall 2004 28

The Overall XP Lifecycle

Fall 2004 29

XP Path

Fall 2004 30

XP Development

Fall 2004 31

XP Collective Code Ownership

Fall 2004 32

Lessons Learned

Fall 2004 33

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.