This document provides an overview of Extreme Programming (XP), a popular agile software development methodology. It discusses the core principles and practices of XP, including rapid feedback, simplicity, incremental changes, embracing change, quality work, pair programming, collective code ownership, continuous integration, testing, refactoring, coding standards, and more. The document also outlines the values that XP is based on such as simplicity, communication, feedback, respect, and courage. It concludes that XP brings the development team together to create quality software that can adapt to changing requirements.

1. 0 | P a g e
2014
Extreme Programming (XP)
Dependable Systems
ALI SHAIKH – K1052280

2. 1 | P a g e
Extreme Programming (XP) as a
popular Agile methodology.
Agile Methodology
Agile methodology is an improved way of managing IT projects specially software
development projects. It is different from traditional methods because a project is
divided into sub-projects/tasks and there is frequent delivery of products as once a
sub-project is completed it is released to the customer. It also includes reassessment
of the user requirements during the project life cycle and the new/changed
requirements can be easily adapted and implemented.
On February 2001, a group of seventeen software developers met at Snowbird
resort in Utah and published the Agile Software Development 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 (Beck et al., 2001).
Within the software development context, manifesto items on the left are defined
below:
Individuals and interactions: focus should be on the people and communication
between them.
Working software: delivering software that works will be more useful and
welcoming than presenting lots of documents to the clients in meetings.
Customer collaboration: continuous customer collaboration is very important as it
is not possible to capture all of the requirements fully at the beginning of the software
development cycle.
Responding to change: agile development focuses on quick response to changing
requirements and adaptation of the requirements without stopping the software
development.
In short the purpose of Agile is to deliver better (quality) software with focus on value
and results.

3. 2 | P a g e
Agile is an umbrella term that encompasses many Agile methods which include
Scrum, XP (Extreme Programming), DSDM, Crystal and others. We will look at XP
as a popular Agile methodology in detail.
XP – Extreme Programming
XP stands for Extreme Programming, and is a suite of practices, principles, and
values invented by Kent Beck in the late ‘90s (Martin, 2006). XP is a type of Agile
software development which is intended to improve software quality and quick
response to changing customer requirements. It focuses on frequent delivery or
releases of software in short development cycles, which results in improved
productivity and also introduces breakpoints to allow the adaptation of new customer
requirements. According to Fowler (2003) the Fundamental principles of XP are:
 Rapid Feedback
The time between an action and its feedback is critical to learning and making
changes. Customer has clear insight and understanding of the system and
they can as needed steer the development by providing rapid feedback.
 Assume Simplicity
Simplest solutions are created for every problem and the focus in on the
requirements that are required only.
 Incremental Change
Delivering a big release at once does not work thus there is incremental
change where small functionalities are added to the system over short
iterations.
 Embracing Change
If customer requirements are changed dramatically these changes are
embraced and planned for the next iteration.
 Quality Work
Build a system that works, adds value to the customer’s business and which
is not expensive to maintain over the long term.
XP Practices
There are twelve XP practices which are listed below (Brewer, 2001; Withrow, 2001;
Martin, 2006):
1. The Planning Game (User stories)
XP involves development iteration periods which are typically 1-2 weeks long.
Before each iteration desired features are defined by the customer in the form of
small stories consisting of about 3 sentences. The developers then take these

4. 3 | P a g e
stories and estimate how long it would take to implement the features. In the end
customer decides which stores to implement and in what order.
2. Small Releases
The application is delivered in a series of small and frequent releases. As each
feature is added, the system keeps developing until all the features have been
implemented.
3. System Metaphor
XP requires set and easy to remember naming conventions for items such as
variable names, methods and class names and thus each project has its own
metaphor.
4. Simple Design
Don’t over complicate the tasks and only use the simplest possible design that
gets the job done. As the requirements can change tomorrow, only do the
tasks/requirements set for today.
5. Continuous Testing
There are two types of tests in XP:
Unit Tests: Programmers write the tests first for a particular requirement and then
code to meet the requirements of the test this flushes out the problems before
they can affect the whole system.
Acceptance Tests: Tests specified by the customer to check if the overall system
is functioning as specified or not. A user story is not deemed complete until it
passes all of the acceptance tests.
6. Refactoring
Code is continuously reviewed to make sure that it is clean i.e. no duplicate/bad
code is included. The standard of XP is not just that the code works but it must
also be clean.
7. Pair Programming
Two heads are better than one and thus the coding is done by two programmers
working on one machine. If one makes a mistake or cannot figure out a problem
the other can fix the mistake or help resolve the problem.
8. Collective Code Ownership
Codebase or a certain module does not belong to an individual. At any time any
developer can work on any part of the system.
9. Continuous Integration
System is updated at least daily and new features are added to the system. The

5. 4 | P a g e
system has to be in a deployable state and needs to pass all previous and new
tests.
10.40-Hour Work Week
Programmers need to be on top of their game in order for XP practices to be
effective. That’s why they go home on time because if the programmer is tired or
sleep-deprived they are more likely to make mistakes and this could result is
lower-quality code.
11.On-site Customer
Customer is an integral part of XP development and must always be available to
answer questions as well as establish requirements and set priorities.
12.Coding Standards
Code writing is done in same way using same formats and styles by all team
members. This makes is easier to share the code among team members and
other developers can understand it easily.
Many of the 12 practices work well on their own so you might decide to use some of
them instead of all 12 but in the XP community it is believed that you are not doing
XP if you do not use all 12 practices.
XP Activities
XP proposes the following four activates that are performed within the software
development process (Apogee, n.d.).
1. Coding
In the system development process, coding is considered to be the only
important product and programmers start to code at the very beginning thus
frequent software releases.
2. Testing
In XP main emphasis is on software testing. Many Unit Tests are written to try
and break the code so if code breaks it can be fixed.
3. Listening
Developers don’t always understand the business side of the system to be
developed so they have to listen to the customers to get the correct
requirements for the system.
4. Designing
System can become too complex over the long run if the logic in the system is
not organised by creating a design structure. A good design will avoid as

6. 5 | P a g e
many dependencies as possible so a change in one part of the system does
not affect the other.
XP Values
Wells (2009) says that XP is based on values, it isn’t just a set of rules but rather a
way to work in harmony with your personal and corporate values. The five values of
XP are:
1. Simplicity
Build only the functionalities that are needed and requested. Take simple steps to
complete the task and achieve the goal. Create something which works and can
be maintained for reasonable costs over the long term.
2. Communication
Communication is key to a successful project; the developers working as a team
and communicating on a daily basis to come up with the best possible solution.
3. Feedback
Get feedback and listen carefully when demonstrating the software to the
customer and make changes if needed.
4. Respect
Team members and customers respect each other and every contribution no
matter how small, it is appreciated, no member of the team should be ignored or
unappreciated.
5. Courage
Tell the truth about progress and estimates, don’t be afraid to throw away the
obsolete code no matter how much effort was used on it. Courage lets
developers feel comfortable when refactoring the code and modifying the system
to adapt the changes whenever they occur.
Conclusion
XP brings all of the team members together to create something they can all be
proud of and with enough feedback and customer input this is achieved by following
simplest practices, values and principles. There is no such thing as best
methodology as a methodology can suit one type of projects where as it won’t work
with others, XP is best applied in projects where requirements change rapidly.
According to Martin (2006), XP is the only method that provides deep and profound
disciplines for the way developers do their daily work, he also goes as far to say that
‘None of the other Agile methods are as well defined, or as broad in scope as XP’.

7. 6 | P a g e
Bibliography
Apogee Integration (n.d.) XP Activities. Available at:
https://www.apogeeintegration.com/xp-activities.html [Accessed 29 October 2014].
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.,
Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001) Manifesto for Agile
Software Development. Available at: http://agilemanifesto.org [Accessed 29 October
2014].
Brewer, J. (2001) Extreme Programming (XP) FAQ. Available at:
http://www.jera.com/techinfo/xpfaq.html [Accessed 29 October 2014].
Fowler, M. (2003) PrinciplesOfXP. Available at:
http://martinfowler.com/bliki/PrinciplesOfXP.html [Accessed 29 October 2014].
Martin, R. (2006). Agile and XP Differences. Available at:
http://www.objectmentor.com/omSolutions/agile_xp_differences.html [Accessed 29
October 2014].
Wells, D. (2009) The Values of Extreme Programming. Available at:
http://www.extremeprogramming.org/values.html [Accessed 29 October 2014].
Withrow, S. (2001) Extreme Programming: Do these 12 practices make perfect?
Available at: http://www.techrepublic.com/article/extreme-programming-do-these-12-
practices-make-perfect/ [Accessed 29 October 2014].