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

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

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

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

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

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 there’s 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 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.