Extreme Programming and Agile Development

The one constant in software development is change. As

strange and paradoxical as that statement may sound, its true.
Thus, when we develop software, we should develop it with the
knowledge that it will have to change at some point, and we
should facilitate that change. We know not whether the change
will simply be something minor, or whether the customer has
suddenly decided that what they said they want isnt what they
actually want and what they actually want is completely
different. This is one of the main reasons why the Waterfall
method is never really mentioned as a good project methodology
by the community (the other, I suspect, is that it conjures
images of endless meetings to decide/agree upon things, and very
little of things actually being done).
Thus, Agile Development was born. The very seeds of it
were visible in the 1970 paper Managing the Development of
Large Software Systems written by Dr. Winston Royce (Agile
Methodology). In this, he criticized the waterfall method, and
described software development as being far different from
automobile[s] on an assembly line (Royce in Agile
Methodology). However, Agile is not in itself a development
methodology, but a quality other methodologies may possess.

One of the most widely used of these methodologies is

Extreme Programming (commonly abbreviated XP), which was
originally created by Kent Beck, and detailed in his book
Extreme Programming Explained: Embrace Change (Copeland). The
contents of this book can be summarized into twelve main points
that are viewed as core to XP. These are as follows
1. Customers define application features with user stories
2. XP teams put small releases into production early
3. XP teams use a common system of names and descriptions.
4. Teams emphasize simply-written, object-oriented code that
meets requirements
5. Designers write automated unit tests upfront and run them
throughout the project.
6. XP teams frequently revise and edit the overall code design, a
process called refactoring.
7. Programmers work side by side in pairs, continually seeing and
discussing each others code.
8. All programmers have collective ownership of the code and the
ability to change it.
9. XP teams integrate code and release it to a repository every
few hours and in no case hold on to it longer than a day.
10.Programmers work only 40 hours per week; theres no overtime.

11.A customer representative remains on-site throughout the

development project.
12.Programmers must follow a common coding standard so all the
code in the system looks as if it was written by a single
individual.

However, XP is not without its detractors, and one of the most

controversial of these points is point #7: Pair Programming.
Coding by yourselfit's easy to get distracted; you're not as
disciplined it's like having your conscience sitting next to
you (Mackinnon in Copeland) claims Tim MacKinnon, a senior
developer at the London based company Connextra Ltd. I can see
his point, and I have made several mistakes that would have
easily been caught by another pair of eyes, as well as been that
pair of eyes to another. I could not do it personally however,
at least not to the extent they are suggesting, as my personal
style is quite different from those of the people I have
programmed with.

user stories
values
acceptance test criteria
iteration plan

simple design
CRC cards

spike solutions
prototypes

refactoring
pair
programming

Release

unit test
continuous integration

software increment
project velocity computed

acceptance testing

Fig. 1: Average lifecycle of an XP Project

To get an idea of what the average XP project looks like, I
have included a diagram of the lifecycle of an average XP
project, and you can quite clearly see that XP is a circular
methodology, where you repeat the process until your software is
developed the way you want it to be.
To wrap things up, when youre developing software, you
need a methodology to guide your development, or you will
quickly end up lost. Among those methodologies, Agile is one of
the most popular categories, and among the Agile methodologies,
Extreme programming is one of the most widely used. Hopefully,
you now have an idea what XP is in general, and why it has
attained the popularity it has.

Works Cited
"Agile Methodology." Agile Methodology. Agile Alliance, n.d.
Web. 24 Mar. 2016.
Copeland, Lee. "Extreme Programming." Computerworld. N.p., n.d.
Web. 24 Mar. 2016.