1. Extreme Programming (XP) XP is an agile methodology: –aims to be responsive to change Theme running through XP is the importance of communication –amongst developers –between developers and customers –between developers and code (e.g. unit tests)

2. Why “extreme”? “XP takes commonsense principles and practices to extreme levels –If code reviews are good, we’ll review code all the time (pair programming) –If testing is good, everybody will test all the time (unit testing), even the customers (functional testing) –If design is good, we’ll make it part of everybody’s daily business (refactoring) ” [Beck, p. xv]

3. Four Variables Cost – how much money? Time – when must software be delivered? Quality – should always be high. Scope – how much functionality? Customers get to pick the value of 3 of the 4, typically Cost, Time and Quality (which should always be high). Developers get to pick the value of the last (typically Scope), indirectly through time estimates

4. Is this the cost of change?

5. What if this were the cost of change?

6. Flattening the cost-of-change curve If cost of change is low, you can “defer the cost of making … decisions and … have the greatest possible chance that they [your decisions] would be right.” [Beck, p. 24] What enables a flatter cost-of-change curve? –Simple design – don’t try to anticipate what the customer will need or want (let them tell you, or ask them!) –Automated tests – executable specification of required functionality. –“XP is making a bet. It is betting that it is better to do a simple thing today and pay little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway.” [Beck, p. 31]

7. Good design is critical Without good design, code quickly deteriorates and becomes fragile Well designed code remains pliable Keys to good design: –Design Patterns –Refactoring (to patterns)

8. 12 principles of XP [Beck, p. 54] 1.The planning game 2.Small releases 3.Metaphor 4.Simple design 5.Testing 6.Refactoring 7.Pair programming 8.Collective ownership 9.Continuous integration 10.40-hour week (sustainable pace) 11.On-site customers 12.Coding standards

9. The planning game Business people decide scope (read: integration thread) priority (if only one of A and B, which one?) composition of releases dates of releases Technical people decide estimates (how long will a feature take) consequences (of technical decisions) process (how will team work and be organized) detailed scheduling (within a release, what is order of work?)

10. More on planning Plan in detail only what you will work on in detail prior to the next planning meeting. “This doesn’t mean you can’t do long-range planning. You can, just not in great detail.” [Beck, p. 85]

11. Goal of the “Planning Game” “The goal of the game is to maximize the value of software produced by the team.” [Beck, p. 87] Customer writes stories (things the system must do). Developers estimate stories (give estimated time to complete a story). Customer prioritizes stories and picks the composition of the next release.

12. Small releases “Every release should be as small as possible, containing the most valuable business requirements.” [Beck, p. 56] Why? Get more frequent, more immediate and more valuable feedback from the customer.

13. Metaphor “Each XP software project is guided by a single overarching metaphor.” [Beck, p. 56] “The metaphor in XP replaces much of what other people call “architecture”. The problem with calling the 10,000-meter view of the system an architecture is that architectures don’t necessarily push the system into any sense of cohesion. An architecture is the big boxes and connections.” [Beck, p. 56]

14. Simple design “The right design for the software at any given time is the one that 1.Runs all the tests. 2.Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies. 3.State every intention important to the programmers. 4.Has the fewest possible classes and methods.” [Beck, p. 57]

15. Testing TDD (Test Driven Development) “Any program feature without an automated test simply doesn’t exist.” [Beck, p. 57] Tests keep code pliable because developers have the security of knowing that if code changes break functionality, tests will fail.

16. Refactoring A refactoring is a functionality-preserving code change. The goal of refactoring should be a design pattern. “After they have added a feature, the programmers ask if they now can see how to make the program simpler, while still running all of the tests. This is called refactoring.” Just like the support of an automated testing framework enables TDD, support for refactoring in the development environment makes it feasible to do.

17. Pair programming “All production code is written with two people looking at one machine, with one keyboard and one mouse.” [Beck, p. 58] “Pairing is dynamic. If two people pair in the morning, in the afternoon they might easily be paired with other folks.” [Beck, p. 59] Pair programming increases communication between developers. Pair programming makes the team less dependent on any one person. Pair programming fosters continuous code review. Personality conflicts? These people don’t have to pair. Studies have shown that two people working as a pair are more productive, and produce higher quality code, than two working individually to solve the same problem.

18. Collective ownership “Collective ownership is this seemingly crazy idea that anyone can change any piece of code in the system at any time. Without the tests, you’d simply be dead trying to do this. With the tests, and the quality of tests you get after a few months of writing lots of tests, you can away with this. You can get away with this if you integrate a few hours worth of changes at a time. Which, of course, is exactly what you will do.” [Beck, p. 99]

19. Collective ownership (continued) “Collective ownership tends to prevent [overly] complex code from entering the system in the first place.” [Beck, p. 99] “On an XP project you are never stuck with someone else’s stupidity. You see something in the way, you get it out of the way.” [Beck, p. 99] “Collective ownership tends to spread knowledge of the system around the team. […] This further reduces project risk.” [Beck, p. 100] Collective ownership together with pair programming are even more effective at spreading knowledge of the system, and minimizing risk. The practices support each other.

20. Continuous integration “No code sits unintegrated for more than a couple of hours. At the end of every development episode, the code is integrated with the latest release and all the tests must run at 100%.” [Beck, p. 98] “It is important to have tools that support a fast integration/build/test cycle.” [Beck, p. 98] Benefits: –The integrated code always compiles, runs, and passes all tests. This code is always ready to put into production. –Integration issues are resolved on an ongoing basis. Integration is part of your everyday activities, and not a separate phase during which lots of new and unforeseen problems crop up.

21. 40-hour week (sustainable pace) People don’t work well if they are continuously stressed. A pressure-cooker type environment leads to burn- out. Developers are people too – they have lives outside of work, which really are more important than work. Once in a while overtime may be needed – but don’t put in overtime two weeks in a row.

22. On-site customer Write functional tests. They provide valuable feedback to the team. Response is immediate – no need to schedule a meeting or play telephone tag. Customer should be set up with whatever they need to continue to do their primary job on-site.

23. Coding standards Development team must settle on coding standards for the project ahead of time. “Curly-brace wars” are completely unproductive. Environments/code formatters can help enforce coding standard with minimal burden on developers.

24. Questions? Comments? Observations? Experience??