Extreme Programming

Extreme Programming Based on the book Extreme Programming, by Kent Beck, Addison Wesley, 1999. Peter Cappello

XP: Outline • The Problem • The Solution • Implementing XP

The Problem: Outline • Risk: The Basic Problem • Economics of Software Development • 4 Variables • Cost of Change • Learning to Drive • 4 Values • Basic Principles • Back to Basics

XP Addresses Our Basic Risks • Problem: Schedule slips • XP Solution: • Tiny releases – a couple of months • Tiny increments – 1 - 4 weeks • Tiny tasks – 1 – 3 days • Implement features in client priority order.

XP Addresses Our Basic Risks • Problem: Project canceled • XP Solution: • Client chooses smallestbusiness sensible release • Less to go wrong • Value to client is greatest

XP Addresses Our Basic Risks • Problem: Finished project: • buggy • Unmaintainable • XP Solution: • XP maintains a test suite • Test suite runs after every baseline change. • Test suite is comprehensive • Test[s] for every feature & method

XP Addresses Our Basic Risks • Problem: Project leaves customer unsatisfied • XP Solution: • In XP, client is part of team. • Specification continuously refined. • Learning by client & developer reflected in: • specification • code.

XP Addresses Our Basic Risks • Problem: False feature rich • XP Solution: • In XP, features are implemented according to client’s priority.

XP Addresses Our Basic Risks • Problem: Programmer turnover • XP Solution: • Programmer • responsible for estimating & completing own tasks • gets feedback on actual time, improving estimates. • New developer responsibilities start small. • XP encourages contact between team members.

Economics of Software Development • 4 project options, at any time, are to: • Abandon • Minimize losses incurred. • Switch • ExpertCity switched product focus. • Defer • Which other option may be clearer in time. • Grow • Can the project make use of more resources? • XP purports to support these options better.

Economics of Software DevelopmentDegree of Uncertainty  a Strategy • Accurate/frequent feedback about progress • Many chances to change requirements. • A small initial investment. • The opportunity to go faster. • Greater uncertainty  XP

Costs vs. Value to Client Over Time COST XP reduces cost of: abandoning switching Waterfall Method TIME TIME XP

Example • Suppose: • Adding a feature costs $10. • You estimate its value is $15. • Then, net present value, NPV = $5. • Your estimate of value could vary by 100% • Adding feature 1 year later = $10. • Then, • @ 5% interest, the value of deferring 1yr = $7.87. • This exceeds the NPV of the feature!

4 Variables • The variables in project management: • Cost • Time • Quality • Scope • The client sets values for 3 of these. • The team then sets the 4th variable’s value.

4 Variables ... • Time • The Mythical Man-Month - If 9 woman cannot produce a baby in 1 month, using 18 woman will not help. • Cost • Like time, throwing money at schedule has limited power.

Quality • Reducing quality to save time/money dooms the project. • People hate making crappy things. • High quality (e.g., unit tests): • often saves both in the short run • usally saves both in the long run.

Scope • Requirements are never clear at first. • Using software affects understanding. • Small increments: • quality feedback homes in fastest on features client likes • give developer experience estimating • implement client’s most important features • If project stops, least important features are lost.

Cost of Change • Conventional wisdom Cost of change Requirements Analysis Design Implementation Test Production

Cost of Change “A problem fixed in the requirements phase for $1 can take $1000s to fix in the production phase.” • If this premise is false, then much of software engineering is wrong-headed. • The curve has been flattened by: • UML, OOD, OODB, IDE, CASE, patterns, refactoring • This is the central premise of XP.

Cost of Change ... • The curve flattens when: • The design is simple. It contains nothing that might be useful only later. • Regression tests are automated. • Design modification is easy. Skill comes from lots of thoughtful experience.

Learning to Drive Controlling software development is like controlling a car: • Many small adjustments • Clear feedback when we are a little off • Many opportunities to correct • Cost of correction needs to be small.

Everything Is Changing • Everything is changing • The requirements • The design • The business • The technology • The team

Driving Metaphor • The customer is the the driver of a project. • Developers are the steering wheel. • They give feedback by delivering small increments. • Each increment also is an opportunity for a small adjustment.

4 Values 1. Communication • Problems result from communication failure. • XP causes communication by requiring: • Unit testing • Pair programming • Task estimation • The coach keeps people communicating.

4 Values ... 2.Simplicity • Implementing a simple design is: • easier • higher quality • on time. • Coach: • “What is the simplest design that works?” (KISS) • Add unnecessary features to the RAD.

4 Values … Simplicity ... Better do: a simpler thing today, risking cost of change Then a complex thing today, that is never needed

4 Values … 3. Feedback • Minutes & days: • Programmers give feedback to: • Themselves: write unit test for all logic. • Customer: immediately estimate cost of feature. • Weeks: • Customer & testers review/adjust schedule. • Months: • System is put in production at earliest possible time. • Giving customer highest quality feedback.

4 Values … 4. Courage • Sometimes the next “small” increment requires a BIG design change. • Simplicity makes BIG changes smaller. • KISS requires courage. • Feedback supports courage: • A BIG change is less scary, if you have a comprehensive tests • and a good version control system.

Basic Principles The principles to judge XP by: • Rapid feedback • Assume simplicity • Incremental change • Embracing change • Quality work

Basic PrinciplesRapid Feedback • Psychology • A key to learning is rapid feedback. • Strategy: • Get feedback rapidly • Interpret it; learn from it • Quickly incorporate lessons into system. • Small increments

Basic PrinciplesAssume Simplicity • Assume the problem has a simple solution. • 98% of the time you are right. • 2% of the time, you are wrong. • you now have more time for those problems. • Do not design for reuse. • Unless the project IS a class library. • Assume refactoring is easy, cheap. • Software economics as options supports this view.

Basic PrinciplesIncremental Change • Many aspects change incrementally: • Requirements • Design • Team • Adoption of XP

Basic PrinciplesEmbrace Change • Strategy 1: Change is expensive. • Shun it. • Design to avoid it. • Strategy 2: Change is inevitable. • Get comfortable with it. • Work to accommodate it.

Basic PrinciplesQuality Work • Nobody feels good about shoddy work. • Quality is not truly a control variable. • Reducing quality reduces morale.

Basic PrinciplesOther Principles • The initial investments is small. 1st increment is as small as possible. • Play to win • Waste no energy on CYA activity. • EYA! Mooning is a basic success principle. • Test every decision • Get objective feedback on every decision

Basic PrinciplesOther Principles … • Quality & beauty more valuable than my ego. • A code critique is an opportunity to learn. • Accept responsibility. • XP principles are adapted by you. • Accept responsibility. • Travel light • Artifacts maintained:few, simple, valuable.

Back to Basics • What activities are essential? • Coding • Testing • Listening • Designing • That is all! • What do these activities give me?

Back to BasicsCoding What do I get from coding? • Learning • An objective test of whether I understand. • It helps me see the essential details. • A clear concise communication medium • Of the system • Of tests for it.

Back to BasicsTesting What do I get from testing? • An expression of what I want. • Independent of implementation • A test tells me when I’m done coding • When in doubt, write more tests. • [Regression] Testing speeds coding. • Easy, quick to see if I broke something.

Back to BasicsListening What do I get from listening? • I learn what to do. • I learn what to test.

Back to BasicsDesigning What do I get from designing? • A system that is simple to: • code & test. • A system that is easy to change. • XP must encourage good design!

Conclusion • I code because that is my primary product. • I test because that is how I know when I’m done coding. • I listen because that is how I know what to code & test. • I design because that enables me to change my code.

Extreme Programming