XP-eXtreme Programming

1. 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” • Requires “testability” • Main focii • “Communication, simplicity, feedback, courage”

2. The Three Extremos • Ward Cunningham • Kent Beck • Ron Jefferies

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

4. XP Rules of Practice

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

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

7. 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 Squeak) allow for running all unit tests. • When a bug is found, a new unit test is written to catch for that bug in the future

8. SUnit

9. Investigating a failed test

10. Debugging a Failed Test

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

12. Does Pair Programming work? • Laurie Williams’ UNC-CH 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!

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

14. Integrate Constantly • Developers should be integrating and releasing code into the code repository every few hours, when ever 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

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

16. 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. • Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is 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.

17. 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 our selves 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

18. One of Four Hats • Kent Beck: • When you are coding you should only be wearing one of four different hats. • Refactoring code, but only changing the interface • Refactoring code, but only changing the implementation • Adding new functionality, but only changing the interface • Adding new functionality, but only changing the implementation.

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

20. 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 • 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)

21. XP is against “BigDesignUpFront” • 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.”

22. 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", cf DonKnuth, and no one has used them. Too bad, really, they were cool.

23. 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. “AlmostXP is like being AlmostAlive or AlmostSolvent.” • 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

24. XP Path

25. XP Development

26. XP Collective Code Ownership

27. Lessons Learned

28. References • http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap • http://www.extremeprogramming.org/