Extreme Programming Iterative programming Agile 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-to-medium-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 Technical 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 How does the whole system work? 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 Pair-Think Pair-Relaying 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 Expert paired with a Novice 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 Refactoring: If you are adding functionality – you are not refactoring! Although you may need to refactor before adding funtionality. Metaphor example: Pub/Sub system has Publishers Subscribers Topics Messages Does not need to be overly abstracted.

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 Code is released into current baseline on integration machine All tests are run 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