Extreme Programming Iterative programming Software developed in iterations

Extreme Programming • Iterative programming – Software developed in iterations – Software evolution becomes THE development technique • Agile programming – Iterative programming without excessive overhead (modeling, etc. ), short releases

Extreme Programming • Extreme programming – An example of agile development – is "a lightweight methodology for small-tomedium-sized teams developing software in the face of vague or rapidly changing requirements"

EXtreme Programming • Everything is carried to extreme • if code reviews are good, review code all the time (pair programming) • if testing is good, test all the time (test-first) • if refactoring is good, refactor all the time • if simplicity is good, design with the simplest design that supports current functionality • if architecture is important, everybody works on defining and refining the architecture all the time • if integration testing is important, integrate and test several times a day • if short iterations are good, make the iterations extremely short (hours, days, weeks)

List of 12 specific practices • • • The planning game Small releases Metaphor Simple design Test first Refactoring Pair programming Collective ownership Continuous integration 40 -hour week On-site customer Coding standards

The Rules and Practices • Planning: Feedback down to just minutes. • Designing: Simple, distributed across the team, based on oral tradition. • Coding: High quality from start to finish, team level development. • Testing: Two levels of testing, one for the customer and one for the developer.

The planning game • Business decisions – Scope: which “stories” should be developed – Priority of stories • Technical decisions – – Time estimates for features/stories Elaborate consequences of business decisions Team organization and process Scheduling

Iteration Planning • Customers choose stories to do. • Management determines the project velocity based on Yesterday’s Weather. • Developers break stories into tasks. • Developers estimate tasks. • Management calculates iteration content. • (Customers choose stories not to do. )

Simple design • The “right” design – No code duplication – Fewest possible classes and methods – Fulfills all current business requirements Design for today not the future

Small releases • Put system into production ASAP – Fast feedback • Deliver valuable features first • Short cycle time – Planning 1 -2 weeks is easier than planning 1 -2 months • Releases should be – as small as possible – containing the most valuable business requirements – "coherent" (you can't release just for the sake of releasing)

Metaphor • Metaphor – for example, the ATM, the contract – metaphor as shared verbal vision of architecture • architecture is boxes and connection • metaphor is holistic, and can be communicated • How does the whole system work? • What is the overall idea of the system?

Pair programming • • • In XP, programmers work in pairs, sitting together to develop code. This helps develop common ownership of code and spreads knowledge across the team. It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages refactoring as the whole team can benefit from this. Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

This Is Pair Programming

This is NOT Pair Programming

Does Pair Programming Really Work? • Empirical study by Laurie Williams at the university of Utah • Practice: Summer 1999 – 20 students (sophomore/junior) • All worked collaboratively – Generated more anecdotal/qualitative evidence • Solo vs. pair: Fall 1999 – 41 students (junior/senior) • 28 worked collaboratively • 13 worked individually – Quantitative: time, quality, enjoyment, confidence

Findings #1 - Quality

Findings #2 - Time

Findings #3 and #4 – Enjoyment and Confidence

How Does This Work? • Pair-Pressure – Keep each other on task and focused – Don’t want to let partner down – “Embarrassed” to not follow the prescribed process • Pair-Think – Distributed cognition: “searching through larger spaces of alternatives” • • Have shared goals and plans Bring different prior experiences to the task Different access to task relevant information Must negotiate a common shared of action • Pair-Relaying – Each, in turn, contributes to the best of their knowledge and ability – Then, sit back and think while their partner fights on

How Does This Work (Part Two)? • Pair-Reviews – Continuous design and code reviews – Ultimate in defect removal efficiency – Removes programmers distaste for reviews • 80% of all (solo) programmers don’t do them regularly or at all • Pair-Learning – Continuous reviews learn from partners techniques, knowledge of language, domain, etc. – “Between the two of us, we knew it or could figure it out” – Apprenticeship – Defect prevention always more efficient than defect removal

Issues: Workplace Layout Bad Better Best

Issues: Partner Picking Principles Expert paired with an Expert paired with a Novices paired together Professional Driver Problem Culture

Issues: Pair Rotation • Ease staff training and transition • Knowledge management/Reduced product risk • Enhanced team building

Pairing Difficulties • Inability to schedule enough time together. • Unreliability of a partner. • Friction caused by different experience levels and/or rates of learning. • Unwillingness to raise these issues in a timely fashion.

Testing • Automatic test drivers • Write tests before production code – Unit tests developer – Feature/acceptance tests customer • Strong emphasis on regression testing – Unit tests need to execute all the time – Tests for completed features need to execute all the time • Unit tests pass 100%

Testing • All code must have unit tests. • All code must pass all unit tests before it can be released. • When a bug is found tests are created. • Acceptance tests are run often and the score is published.

Refactoring • Small changes that do not change the function of the program. • Increase design consistency. • Simplify as you go. • The design you need may not be the one you thought. • Bad smells -> refactoring

Refactoring • Examples: – Remove duplicate code – Leverage existing code – Remove unused code • Refactoring mercilessly requires good unit tests and functional tests that can easily be executed • Goal: Keep design simple – Change bad design when you find it – Remove dead code

Collective Ownership • Nobody owns code • Nobody owns design • Everybody takes responsibility for the whole of the system – not everyone knows every part equally well, but • everybody knows something about every part • everybody knows who to ask – anybody can change or improve anything at any time • The two are crucially interrelated – you can't know what's broken or can be improved unless you have the big picture in your mind

Continuous Integration • Every milestone is an integration milestone • A system of "build the pieces then integrate them at the last minute" – is classic divide and conquer – is doomed to failure • Short development cycle with integration at the end of every cycle

Continuous Integration • Integration happens after a few hours of development 1. Code is released into current baseline on integration machine 2. All tests are run 3. In case of errors: • • • Reverse to old version Fix problems Goto (1)

On-site customer • Many software projects fail because they do not deliver software that meets business needs • Real customer has to be part of the team – Defines business needs – Answers questions and resolves issues – Prioritizes features

Coding standards • Team has to adopt a coding standard – Makes it easier to understand other people’s code – Avoids code changes because of syntactic preferences

Summary • XP is a process based on a set of practices • The practices are based around the bigger ideas of flexibility and involvement, and are all interrelated – "Any one practice doesn't stand on its own. They require the other practices to keep them in balance. " – For example, quick simple design can't work unless you • are able to make changes quickly • have a shared vision of the design • have the big picture in mind • Suitable for small teams, volatile requirements