Extreme Programming Practice Robert Duisberg

1. Extreme Programming PracticeRobert Duisberg

2. Overview I: • What is Extreme Programming (XP)? • Curiously Controversial • A Set of Principles and Practices comprising: • A Software Development Methodology • Which goes against some prevalent impulses • And yet is remarkably productive in practice • Why is XP? • Devised to address a Set of Problems • An alternative to Heavy-weight Processes

3. Overview II: • What is so Extreme about it? • Historical Context • The Problem(s) XP addresses • The Principles and Practices of the Methodology • Real-world Experiences and Contrasts with MS/development Practices • Management Issues • Design Issues

4. What is so Extreme about it? • All the practices are normal and accepted—just pushed. • If short iterations are good – make them really, really short. -- the “Planning Game.” • If code reviews are good – review code all the time. -- Pair programming. • If testing is good – everybody will test all the time. -- Integrated unit testing and acceptance testing. • If design is good – design is an ongoing daily business. -- Constant refactoring. • If simplicity is good – always choose the simplest thing. -- The “simplest thing that could possibly work.” • If integration testing is important – integrate and test several times a day

5. History of Computer Systems Development • Three phases Characterized by: • Hardware Constraints • in 1955 USAF estimated hardware > 80% of cost • by 1965 < 50% • “cottage industry” programming • Software Constraints • At Garmisch 1968 Dijkstra & Perlis articulate the “Software Crisis” • “Today we tend to go on for years, with tremendous investments to find that the system, which was • not well understood to start with, does not work as anticipated. We build systems like the Wright • Brothers built airplanes—build the whole thing, push it off the cliff, let it crash, and start over again.” • Structured and Modular Programming…OOP • User Relations/Needs • Market Developments: Ubiquitous PC’s, LANs, “End-User” computing. • “Commoditization” of computing intensifies market competition.

6. The Problem: Risks • Schedule Slips – 6 months or a year, “standard.” -- Short cycles reduce the scope of slippage and give early warnings. • Project Cancellations – after a few slips, cut it. -- The smallest possible release is put into production immediately. • Defect Rate – so high the software is not used in practice. -- Testing suites ensure quality baseline • Business misunderstood – business problem not properly addressed. -- Customer is part of the team and spec is continually refined. • Business changes – competition and market climates increasingly fluid. -- Short releases + customer involvement allows fluid redirection. • False feature rich – fun to program but not of much value to customers. -- Only the highest priority tasks are addressed in any cycle. • Staff turnover – the gurus who know the code base leave the project. -- Collective “ownership” of code.

7. Four Project Management Variables Trade-offs and interactions among: • Resources Inflexible: too much or too little are both problems • Time More time can improve quality & increase scope. But too much can, again, hurt the project. • Quality A terrible control variable. Gains are only short term. • Scope Restricting scope can improve quality and allow delivery Sooner and cheaper.

8. Options “Eliminate Downside Risk” Project Management can be viewed as a series of Options: • Option to Abandon • Option to Switch • Option to Defer • Option to Grow The Worth of these Options depend on: • The cost to Obtain the option • The cost to Exercise the option (to “Purchase the Prize”) • The current Value of the “Prize” • The amount of Time in which you can exercise the option • The Uncertainty in the eventual Value of the Prize Worth is enhanced by a strategy with: • Accurate and frequent feedback about progress • Many opportunities to dramatically change the requirements • Smaller initial investment • The opportunity to go faster

9. Principles and Practices I The “Planning Game” • Formalized Communication, Negotiation (Requirements) • Feature/Task Specification, Estimation, Prioritization • Formal use of note cards for “Stories” and tasks. Continual Testing • Tests are written before functionality is implemented. • The Test Utility is the console. Run constantly. • Tests are never thrown away. Small Releases • An extremely simple version in production immediately! • Automatic build system runs the full test suite. • Every integration (many times a day) generates a release. • Two week iterations. The Simplest Possible Design at any moment • Do not design for the future! (This goes against the grain) • Extra complexity & unused code is removed as soon as it is discovered.

10. Principles and Practices II Pair Programming • All production code is written with two programmers at one machine. • USB keyboards & mice, 2 at each workstation. Timbuktu for remote. Collective Ownership • Anyone can change any code at any time. Continuous Integration • Task granularity = ~ 3 hours’ work => test & integration. Continual Refactoring • Restructure system to simplify, or improve, without changing function. • Constant process of design refinement. On-site Customer • Available full time for questions/design. 40 Hour Week • Overtime is strongly discouraged. • Overtime two weeks in a row is prohibited.

11. The Planning Game • The Goal • Maximize the value of the software produced. • The 80-20 rule. • The Strategy • Invest as little as possible to create the most valuable functionality as soon as possible. • The 80-20 rule. • The Pieces • “Story” Cards and Task Cards • The Moves • Exploration Phase • Write a Story – set scope • Estimate a Story – set required time • Commitment Phase • Sort by Value and Risk • Set Task Velocity • Implement and Iterate

12. Four XP “Values” • Communication • Project problems invariably trace back to something important failing to be communicated. • Simplicity • “What is the simplest thing that could possibly work?” • Fear of “exponential cost curve” leads to compulsively “thinking ahead.” • Trust in the ability to make changes. • Feedback • “Have you written a test for that yet?” • “Don’t ask me. Ask the system” • Feedback at many time scales and among various folks. • Courage • The other values in place give a programmer the confidence to make the changes that are really needed!

13. How Can this Possibly Work? I: • You can’t start with only a rough plan! You can’t constantly • update the plan! (That would upset the customers!) • Unless: • The customers did the updating of the plans themselves. • Short releases so any mistake in the plan has a small impact. • Your customer is sitting on the team & so can spot opportunities. • You can’t go into production immediately! And you can’t • possibly make daily releases! • Unless: • The Planning Game identified the smallest valuable functionality. • You were integrating continually so costs of a release are nil. • Your continual testing regimen obviates the need for a testing cycle. • You make the simplest possible initial design – subject to change.

14. How Can this Possibly Work? II: • You can’t have just enough design for today’s code! • You would design yourself into a corner! • Unless: • You were always refactoring and making changes isn’t a problem. • You were programming with a partner so you were confident you were making a simple design, not a stupid design. • You can’t possibly write all those tests! • Programmers won’t write tests anyway! • Unless: • The design is as simple as can be so writing tests isn’t that hard. • Your coding partner won’t let you get away without it. • You feel good about seeing all the tests running (and can go home!) • Your customer is happy when their acceptance tests run.

15. How Can this Possibly Work? III: • You can’t refactor the system all the time! • It would take too long and would break everything! • Unless: • All the tests are run so you won’t break anything without knowing. • Continuous integration will alert you to “problems at a distance.” • You are used to collective ownership, and pair programming helps to give you confidence. • Everybody change everything everywhere all the time! • Unless: • You integrate immediately so conflicts don’t develope. • You always write tests, so accidental breakage is avoided. • You pair program, so you learn faster what you can well change.

16. Real-World Experiences • Developing Products for Microsoft • Standard Model: • 18 month development cycle 6 months late • Redesign by Testing • The Arrogance of the “Masters of the Universe” • Burn out! • Developing Products within Quicksilver Technologies • XP Process: • Group quickly proved the most productive in the company! • Extremely social. Programming is fun again! • Personal dynamics and mutual respect are crucial; hiring criteria. • A sense of being in control of one’s life and work. • Confidence that one’s work is useful (wanted) and not arbitrary.

17. Management Issues I: • Business Management must shift from: • Milestone scheduling • Micromanaged design from global specs • Specific costs for deliverables • To: • Process oriented, incremental growth model • Management as process facilitation • Cash flow for accrued value. (But value is incremental! This is key!) This is pretty hard for some managers to do! (And yet XP can subsume the old model…)

18. Management Issues II: • Power should be Split between Business & Development. The results are unfortunate if either group has too much control. • Business should choose: • The scope and timing of releases. • The relative priorities of proposed features. • Exact scope of proposed features. • To these decisions Development Organization must add: • Estimates of the time required to implement various features. • Estimates of the consequences of various technical alternatives. • Choices (and estimates of costs) of technologies, processes & infrastructures.

19. Design Issues I: • The Questions have been asked (by management): • Where does design happen in this process? • If programmers are only task driven, when do you do architecture? • To which I answer • Design happens all the time! (instead of artificially isolated at the front end) • Design (like composition) is a process of Progressive Discovery of the possible. • XP process gives the freedom to continually refine the Design as more is learned about the project/system/market.

20. Design Issues II: • In Winograd’s “Bringing Design to Software” • Clarity of Goals Communication and Sharing of Goals. Goals change, and the Project must as well. • Customer Focus “Customer focus is not just an attitude.” Requires structures & support for staff/customer interaction. • Designer Empowerment Decision-Making power Creativity and Engagement Commitment as opposed to Assignment

21. When is XP Appropriate? (or Not…) • XP works well with: • Small to medium size development teams (Can large teams build software at all, without partition?) • Requirements are vague or rapidly changing (When do customers ever really know what they want?) (Where is there a market that is not rapidly changing?) • XP may fail in a project culture: • that involves large teams. • with a decision making structure that makes change difficult. • with distrustful customers. • dealing with technology that doesn’t support graceful change, e.g. requiring use of large amounts of legacy code. (…Government work…)

22. Referenences Kent Beck, “Extreme Programming Explained,” Addison-Wesley, 2000. http://www.extremeprogramming.org/