Extreme

Programming
Daniel Baranowski
3/29/06
What is Extreme Programming?
 An agile development methodology
 Created by Kent Beck in the mid 1990’s
 A set of 12 key practices taken to their
“extremes”
 A mindset for developers and customers
 A religion?
What is agile?
 Any methodology that subscribes to the Agile Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
What else is agile?
 Adaptive Software Development
 Crystal Methodologies
 Dynamic Systems Development Method
 Feature-Driven Development
 SCRUM
 And others
The 12 Practices
 The Planning Game
 Small Releases
 Metaphor
 Simple Design
 Testing
 Refactoring
 Pair Programming
 Collective Ownership
 Continuous Integration
 40-Hour Workweek
 On-site Customer
 Coding Standards
1 - The Planning Game
 Planning for the upcoming iteration
 Uses stories provided by the customer
 Technical persons determine schedules,
estimates, costs, etc
 A result of collaboration between the
customer and the developers
The Planning Game – Advantages

 Reduction in time wasted on useless

features
 Greater customer appreciation of the cost
of a feature
 Less guesswork in planning
The Planning Game – Disadvantages

 Customer availability
 Is planning this often necessary?
2- Small Releases
 Small in terms of functionality
 Less functionality means releases happen
more frequently
 Support the planning game
Small Releases – Advantages
 Frequent feedback
 Tracking
 Reduce chance of overall project slippage
Small Releases – Disadvantages

 Not easy for all projects

 Not needed for all projects
 Versioning issues
3 – Metaphor
 The oral architecture of the system
 A common set of terminology
Metaphor – Advantages
 Encourages a common set of terms for the
system
 Reduction of buzz words and jargon
 A quick and easy way to explain the
system
Metaphor – Disadvantages
 Often the metaphor is the system
 Another opportunity for miscommunication
 The system is often not well understood as
a metaphor
4 – Simple Design
 K.I.S.S.
 Do as little as needed, nothing more
Simple Design – Advantages
 Time is not wasted adding superfluous
functionality
 Easier to understand what is going on
 Refactoring and collective ownership is
made possible
 Helps keeps programmers on track
Simple Design – Disadvantages
 What is “simple?”
 Simple isn’t always best
6 – Testing
 Unit testing
 Test-first design
 All automated
Testing – Advantages
 Unit testing promote testing completeness
 Test-first gives developers a goal
 Automation gives a suite of regression test
Testing – Disadvantages
 Automated unit testing isn’t for everything
 Reliance on unit testing isn’t a good idea
 A test result is only as good as the test
itself
6 – Refactoring
 Changing how the system does something
but not what is done
 Improves the quality of the system in some
way
Refactoring – Advantages
 Prompts developers to proactively improve
the product as a whole
 Increases developer knowledge of the
system
Refactoring – Disadvantages
 Not everyone is capable of refactoring
 Refactoring may not always be
appropriate
 Would upfront design eliminate
refactoring?
7 – Pair Programming
 Two Developers, One monitor, One
Keyboard
 One “drives” and the other thinks
 Switch roles as needed
Pair Programming – Advantages
 Two heads are better than one
 Focus
 Two people are more likely to answer the
following questions:
 Is this whole approach going to work?
 What are some test cases that may not work
yet?
 Is there a way to simplify this?
Pair Programming – Disadvantages

 http://www.cenqua.com/pairon/
 Many tasks really don’t require two
programmers
 A hard sell to the customers
 Not for everyone
8 – Collective Ownership
 The idea that all developers own all of the
code
 Enables refactoring
Collective Ownership – Advantages

 Helps mitigate the loss of a team member

leaving
 Promotes developers to take responsibility
for the system as a whole rather then parts
of the system
Collective Ownership - Disadvantages

 Loss of accountability
 Limitation to how much of a large system
that an individual can practically “own”
9 – Continuous Integration
 New features and changes are worked
into the system immediately
 Code is not worked on without being
integrated for more than a day
Continuous Integration -
Advantages
 Reduces to lengthy process
 Enables the Small Releases practice
Continuous Integration –
Disadvantages
 The one day limit is not always practical
 Reduces the importance of a well-thought-
out architecture
10 – 40-Hour Week
 The work week should be limited to 40
hours
 Regular overtime is a symptom of a
problem and not a long term solution
40-Hour Week – Advantage
 Most developers lose effectiveness past
40-Hours
 Value is placed on the developers well-
being
 Management is forced to find real
solutions
40-Hour Week - Disadvantages
 The underlying principle is flawed
 40-Hours is a magic number
 Some may like to work more than 40-
Hours
11 – On-Site Customer
 Just like the title says!
 Acts to “steer” the project
 Gives quick and continuous feedback to
the development team
On-Site Customer – Advantages

 Can give quick and knowledgeable

answers to real development questions
 Makes sure that what is developed is what
is needed
 Functionality is prioritized correctly
On-Site Customer – Disadvantages

 Difficult to get an On-Site Customer

 The On-Site customer that is given may
not be fully knowledgeable about what the
company
 May not have authority to make many
decisions
 Loss of work to the customer’s company
12 – Coding Standards
 All code should look the same
 It should not possible to determine who
coded what based on the code itself
Coding Standards – Advantages

 Reduces the amount of time developers

spend reformatting other peoples’ code
 Reduces the need for internal commenting
 Call for clear, unambiguous code
Coding Standards – Disadvantages

 Degrading the quality of inline

documentation
Manager and Customer Bill of Rights
 You have the right to an overall plan, to know what can be
accomplished, when, and at what cost.
 You have the right to get the most value out of every
programming week.
 You have the right to see progress in a running system, proven to
work by passing repeatable tests that you specify.
 You have the right to change your mind, to substitute functionality,
and to change priorities without paying exorbitant costs.
 You have the right to be informed of schedule changes, in time to
choose how to reduce scope to restore the original date. You can
cancel at any time and be left with a useful working system,
reflecting investment to date.
Programmer Bill Of Rights
 You have the right to know what is needed, with clear
declarations of priority.
 You have the right to produce quality work at all times.
 You have the right to ask for and receive help from
peers, superiors, and customers.
 You have the right to make and update your own
estimates.
 You have the right to accept your responsibilities
instead of having them assigned to you.
XP – Advantages
 Built-In Quality
 Overall Simplicity
 Programmer Power
 Customer Power
 Synergy Between Practices
XP – Disadvantages
 Informal, little, or no documentation
 Scalability
 Contract Issues
 Misconception on the cost of change
 Tailoring
Application – Advantageous
 Highly uncertain environments
 Internal projects
 Joint ventures
Application – Disadvantageous
 Large, complex environments
 Safety critical situations
 Well understood requirements
 Distant or unavailable customer
Final Thoughts
 Why XP succeeds
 Why XP is popular
 Why XP fails
 Why XP is not the “silver bullet”
Questions?