EXTREME PROGRAMMING

ABSTRACT
Software reliability has been found to be an important part for measuring success and
longevity of software product. Though there hasn’t really been methods developed to truly can
be considered “accurate” at measuring reliability because all use assumptions and different types
of metrics, they still provide a good guideline as to the reliability of a software product. Because
in today’s development communities that demand for software has increased so dramatically it is
important that software products are reliable, with that said this high demand for software has
pushed many development teams to adopt agile programming practices to keep up with the high
demand. Though agile programming has been proven to be efficient it is important to provide
development teams that do not have the luxury of spending the desired time testing their systems
reliability, that they adopt practices that will ensure their system is more reliable.

Extreme Programming (XP) is a software development methodology which is intended to

improve software quality and responsiveness to changing customer requirements. As a type of
agile software development, it advocates frequent "releases" in short development cycles
(timeboxing), which is intended to improve productivity and introduce checkpoints where new
customer requirements can be adopted.

Other elements of Extreme Programming include: programming in pairs or doing

extensive code review, unit testing of all code, avoiding programming of features until they are
actually needed, a flat management structure, simplicity and clarity in code, expecting changes in
the customer's requirements as time passes and the problem is better understood, and frequent
communication with the customer and among programmers.The methodology takes its name
from the idea that the beneficial elements of traditional software engineering practices are taken
to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy
coding", which is more free-form and unplanned. It does not advocate "death march" work
schedules, but instead working at a sustainable pace.

SSEC I.T. Page 1

 EXTREME PROGRAMMING

Critics have noted several potential drawbacks, including problems with unstable
requirements, no documented compromises of user conflicts, and lack of an overall design spec
or document.

SSEC I.T. Page 2

 EXTREME PROGRAMMING

INTRODUCTION

SOFTWARE DEVELOPMENT PROCESS

A software development methodology or system development methodology in software
engineering is a framework that is used to structure, plan, and control the process of developing
an information system.

OVERVIEW
A software development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. A wide variety of such frameworks
have evolved over the years, each with its own recognized strengths and weaknesses. One system
development methodology is not necessarily suitable for use by all projects. Each of the available
methodologies is best suited to specific kinds of projects, based on various technical,
organizational, project and team considerations.

The framework of a software development methodology consists of:

 A software development philosophy, with the approach or approaches of the software

development process

 Multiple tools, models and methods, to assist in the software development process.

These frameworks are often bound to some kind of organization, which further develops,
supports the use, and promotes the methodology. The methodology is often documented in some
kind of formal documentation.

SOFTWARE DEVELOPMENT APPROACHES

SSEC I.T. Page 3

 EXTREME PROGRAMMING

Every software development methodology has more or less its own approach to software
development. There is a set of more general approaches, which are developed into several
specific methodologies. These approaches are:

 Waterfall: linear framework type.

 Prototyping: iterative framework type

 Incremental: combination of linear and iterative framework type

 Spiral: combination linear and iterative framework type

 Rapid Application Development (RAD): Iterative Framework Type

AGILE SOFTWARE DEVELOPMENT

SSEC I.T. Page 4

 EXTREME PROGRAMMING

Agile software development refers to a group of software development methodologies

based on iterative development, where requirements and solutions evolve through collaboration
between self-organizing cross-functional teams. The term was coined in the year 2001 when the
Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that

encourages frequent inspection and adaptation, a leadership philosophy that encourages
teamwork, self-organization and accountability, a set of engineering best practices intended to
allow for rapid delivery of high-quality software, and a business approach that aligns
development with customer needs and company goals.

Conceptual foundations of this framework are found in modern approaches to operations

management and analysis, such as lean manufacturing, soft systems methodology, speech act
theory (network of conversations approach), and Six Sigma.

OVERVIEW

There are many specific agile development methods. Most promote development,
teamwork, collaboration, and process adaptability throughout the life-cycle of the project. One of
the early metrics showing Agile method is more productive than other methods is a Dr. Dobb's
Journal survey. Others claim that agile development methods are still too young to require
extensive academic proof of their success.

Agile methods break tasks into small increments with minimal planning, and do not
directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically
last from one to four weeks. Each iteration involves a team working through a full software
development cycle including planning, requirements analysis, design, coding, unit testing, and
acceptance testing when a working product is demonstrated to stakeholders. This helps minimize
overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation
as required.

Team composition in an agile project is usually cross-functional and self-organizing

without consideration for any existing corporate hierarchy or the corporate roles of team

SSEC I.T. Page 5

 EXTREME PROGRAMMING

members. Team members normally take responsibility for tasks that deliver the functionality an
iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the
team is all in the same location. When a team works in different locations, they maintain daily
contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such
communication. Team size is typically small (5-9 people) to help make team communication and
team collaboration easier. Larger development efforts may be delivered by multiple teams
working toward a common goal or different parts of an effort. This may also require a
coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a
customer representative. This person is appointed by stakeholders to act on their behalf and
makes a personal commitment to being available for developers to answer mid-iteration problem-
domain questions. At the end of each iteration, stakeholders and the customer representative
review progress and re-evaluate priorities with a view to optimizing the return on investment and
ensuring alignment with customer needs and company goals.

Agile emphasizes working software as the primary measure of progress. This, combined
with the preference for face-to-face communication, produces less written documentation than
other methods. The agile method encourages stakeholders to prioritize wants with other iteration
outcomes based exclusively on business value perceived at the beginning of the iteration.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair
programming, test driven development, design patterns, domain-driven design, code refactoring
and other techniques are often used to improve quality and enhance project agility.

HISTORY

The modern definition of agile software development evolved in the mid-1990s as part of
a reaction against "heavyweight" methods, perceived to be typified by a heavily regulated,
regimented, micro-managed use of the waterfall model of development. The processes
originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and

SSEC I.T. Page 6

 EXTREME PROGRAMMING

inconsistent with the ways that software developers actually perform effective work. A case can
be made that agile and iterative development methods mark a return to development practice
from early in the history of software development.Initially, agile methods were called
"lightweight methods."

An adaptive software development process was introduced in a paper by Edmonds

(1974). Notable early Agile methods include Scrum (1995), Crystal Clear, Extreme
Programming (1996), Adaptive Software Development, Feature Driven Development, and
Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as
Agile Methodologies, after the Agile Manifesto published in 2001.

In 2001, 17 prominent figures in the field of agile development (then called "light-weight
methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software
in a lighter, faster, more people-centric way. They coined the terms "Agile Software
Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the
canonical definition of agile development and accompanying agile principles. Later, some of
these people formed The Agile Alliance, a non-profit organization that promotes agile
development.

PRINCIPLES

Agile methods are a family of development processes, not a single approach to software
development. The Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:

SSEC I.T. Page 7

 EXTREME PROGRAMMING

 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.

Some of the principles behind the Agile Manifesto are:

 Customer satisfaction by rapid, continuous delivery of useful software

 Working software is delivered frequently (weeks rather than months)

 Working software is the principal measure of progress

 Even late changes in requirements are welcomed

 Close, daily cooperation between business people and developers

 Face-to-face conversation is the best form of communication (co-location)

 Projects are built around motivated individuals, who should be trusted

 Continuous attention to technical excellence and good design

 Simplicity

 Self-organizing teams

 Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry known as agile software
development.

SSEC I.T. Page 8

 EXTREME PROGRAMMING

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people—
management experts, this time—and wrote an addendum, known as the PM Declaration of
Interdependence.

The functioning principles of Agile can be found in lean manufacturing and six sigma.
These concepts include error proofing, eliminating waste, creating flow, adding customer value,
and empowering workers. The concepts were first formally espoused in the 14 principles of the
Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart
automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the
seven points of lean software development.

COMPARISON WITH OTHER METHODS

Agile methods are sometimes characterized as being at the opposite end of the spectrum
from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that
agile methods are "unplanned" or "undisciplined". A more accurate distinction is that methods
exist on a continuum from "adaptive" to "predictive". Agile methods lie on the "adaptive" side of
this continuum.

Adaptive methods focus on adapting quickly to changing realities. When the needs of a
project change, an adaptive team changes as well. An adaptive team will have difficulty
describing exactly what will happen in the future. The further away a date is, the more vague an
adaptive method will be about what will happen on that date. An adaptive team can report
exactly what tasks are being done next week, but only which features are planned for next month.
When asked about a release six months from now, an adaptive team may only be able to report
the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team
can report exactly what features and tasks are planned for the entire length of the development
process. Predictive teams have difficulty changing direction. The plan is typically optimized for
the original destination and changing direction can cause completed work to be thrown away and

SSEC I.T. Page 9

 EXTREME PROGRAMMING

done over differently. Predictive teams will often institute a change control board to ensure that
only the most valuable changes are considered.

Agile methods have much in common with the "Rapid Application Development"
techniques from the 1980/90s as espoused by James Martin and others.

CONTRASTED WITH OTHER ITERATIVE DEVELOPMENT METHODS

Most agile methods share other iterative and incremental development methods' emphasis
on building releasable software in short time periods. Agile development differs from other
development models: in this model time periods are measured in weeks rather than months and
work is performed in a highly collaborative manner. Most agile methods also differ by treating
their time period as a timebox.

CONTRASTED WITH THE WATERFALL METHODOLOGY

Agile development has little in common with the waterfall model. The Waterfall
methodology is the most structured of the methods, stepping through requirements, analysis,
design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often
measured in terms of deliverable artifacts: requirement specifications, design documents, test
plans, code reviews and the like.

A common criticism of the waterfall model is its inflexible division of a project into
separate stages, where commitments are made early on, making it difficult to react to changes in
requirements as the project executes. This means that the waterfall model is likely to be
unsuitable if requirements are not well understood/defined or change in the course of the project.

Agile methods, in contrast, produce completely developed and tested features (but a very
small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable
piece of functionality to deliver business value early and continually improving it and/or adding
further functionality throughout the life of the project. If a project being delivered under
Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a

SSEC I.T. Page 10

 EXTREME PROGRAMMING

huge resources bill. With Agile, being cancelled at any point will still leave the customer with
some worthwhile code that has likely already been put into live operation.

Adaptations of Scrum show how agile methods are augmented to produce and
continuously improve a strategic plan.

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall
cycle in every iteration.Other teams, most notably Extreme Programming teams, work on
activities simultaneously.

SUITABILITY OF AGILE METHODS

There is little if any consensus on what types of software projects are best suited for the
agile approach. Many large organizations have difficulty bridging the gap between the traditional
waterfall method and an agile one.

Large scale agile software development remains an active research area.

Some things that can negatively impact the success of an agile project are:

 Large scale development efforts (>20 developers), though scaling strategies and evidence
to the contrary have been described.

 Distributed development efforts (non-co-located teams). Strategies have been described

in Bridging the Distance and Using an Agile Software Process with Offshore
Development.

 Forcing an agile process on a development team.

 Mission critical systems where failure is not an option at any cost (Software for surgical
procedures).

Several successful large scale agile projects have been documented.BT has had several
hundred developers situated in the UK, Ireland and India working collaboratively on projects and
using Agile methods. While questions undoubtedly still arise about the suitability of some Agile

SSEC I.T. Page 11

 EXTREME PROGRAMMING

methods to certain project types, it would appear that scale or geography, by themselves, are not
necessarily barriers to success.

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between
adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of
the continuum has its own home ground as follows:

Agile home ground:

 Low criticality

 Senior developers

 Requirements change often

 Small number of developers

 Culture that thrives on chaos

Plan-driven home ground:

 High criticality

 Junior developers

 Requirements do not change often

 Large number of developers

 Culture that demands order

SSEC I.T. Page 12

 EXTREME PROGRAMMING

EXTREME PROGRAMMING
A traditional software development model proceeds incrementally from specification,
through design, coding, integration and testing, and package release. A single release cycle
typically lasts several months – perhaps even a year or more. While this approach allows a great
level of planning and thoughtful design, difficulties may arise when customers change their
minds or conditions change.

Extreme programming or XP represents a dramatically different approach, with release

cycles measured in days – up to a few weeks. Product development involves customers on an
active and continuous basis, testing comes before coding, integration occurs daily (or more
often), and pair programming is a way of life.
SSEC I.T. Page 13
 EXTREME PROGRAMMING

This session will highlight the twelve practices of XP, compare this approach to a
traditional model, and consider advantages and disadvantages of the approach.

The first Extreme Programming project was started March 6, 1996. Extreme
Programming is one of several popular Agile Processes. It has already been proven to be very
successful at many companies of all different sizes and industries worldwide.

Extreme Programming is successful because it stresses customer satisfaction. Instead of

delivering everything you could possibly want on some date far in the future this process delivers
the software you need as you need it. Extreme Programming empowers your developers to
confidently respond to changing customer requirements, even late in the life cycle.

Extreme Programming (XP) is about social change. It is about letting go of habits and patterns
that were adaptive in the past, but now get in the way of us doing our best work. It is about
giving up the defenses that protect us but interfere with our productivity. It may leave us feel-

ing exposed. It is about being open about what we are capable of doing and then doing it. And,
allowing and expecting others to do the same. It is about getting past our adolescent surety that “I
know better than everyone else and all I need is to be left alone to be the greatest.” It is about
finding our adult place in the larger world, finding our place in the community including the
realm of business/work. It is about the process of becoming more of our best selves and in the
process our best as developers. And, it is about writing great code that is really good for business.
Good relationships lead to good business. Productivity and confidence are related to our human
relationships in the workplace as well as to our coding or other work activities. You need both
technique and good relationships to be successful. XP addresses both. Prepare for success. Don’t
protect yourself from success by holding ack. Do your best and then deal with the consequences.
That xtreme. You leave yourself exposed. For some people that is incredily scary, for others it’s
daily life. That is why there are such polarized eactions to XP.

XP is a style of software development focusing on excellent application of programming

techniques, clear communication, and teamworkwhich allows us to accomplish things we
previously could not even magine. XP includes:

SSEC I.T. Page 14

 EXTREME PROGRAMMING

 A philosophy of software development based on the values of communication, feedback,

simplicity, courage, and respect.

 A body of practices proven useful in improving software development. The practices

complement each other, amplifying their effects. They are chosen as expressions of the
values.

 A set of complementary principles, intellectual techniques for translating the values into
practice, useful when there isn’t a practice handy for your particular problem.

 A community that shares these values and many of the same practices.

 XP is a path of improvement to excellence for people coming together to develop

software. It is distinguished from other methodologies

 Its short development cycles, resulting in early, concrete, and continuing feedback.

 Its incremental planning n approach, which quickly comes up with an overall plan that is
expected to evolve through the life of the project.

 Its ability to flexibly schedule the implementation of functionality, responding to

changing business needs.

SSEC I.T. Page 15

 EXTREME PROGRAMMING

 Its reliance on automated tests written by programmers, customers, and testers to

monitor the progress of development, to allow the system to evolve, and to catch defects
early.

 Its reliance on oral communication, tests, and source code to

communicate system structure and intent.

 Its reliance on an evolutionary design process that lasts as long as

the system lasts.

 Its reliance on the close collaboration of actively engaged individuals with ordinary
talent.

 Its reliance on practices that work with both the short-term instincts

of the team members and the long-term interests of the project.

XP is a software development discipline that addresses risk at all levels of the development
process. XP is also productive, produces high quality software, and is a lot of fun to execute.
How does XP address the risks in the development process?

 Schedule slips—XP calls for short release cycles, a few months at most, so the scope of
any slip is limited. Within a release, XP uses one-week iterations of customer-requested
features to create fine-grained feedback about progress. Within an iteration, XP plans

SSEC I.T. Page 16

 EXTREME PROGRAMMING

with short tasks, so the team can solve problems during the cycle.Finally, XP calls for
implementing the highest priority features first,so any features that slip past the release
will be of lower value.

 Project canceled—XP asks the business-oriented part of the team to choose the smallest
release that makes the most business sense, so there is less to go wrong before deploying
and the value of the software is greatest.

 System goes sour—XP creates and maintains a comprehensive suite of automated tests,
which are run and rerun after every change (many times a day) to ensure a quality
baseline. XP always keeps the system in deployable condition. Problems are not allowed
to accumulate.

 Defect rate—XP tests from the perspective of both programmers writing tests function-
by-function and customers writing tests program-feature-by-program-feature.

 Business misunderstood—XP calls for business-oriented people to be first-class

members of the team. The specification of the projectis continuously refined during
development, so learning by the customer and the team can be reflected in the software.

 Business changes—XP shortens the release cycle, so there is less change during the
development of a single release. During a release, the customer is welcome to substitute
new functionality for functionality not yet completed. The team doesn’t even notice if it
is working on newly discovered functionality or features defined years ago.

SSEC I.T. Page 17

 EXTREME PROGRAMMING

 False feature rich—XP insists that only the highest priority tasks are addressed.

 Staff turnover—XP asks programmers to accept responsibility for estimating and

completing their own work, gives them feedback about the actual time taken so their
estimates can improve, and respects those estimates. The rules for who can make and
change estimates are clear. Thus, there is less chance for a programmer to get frustrated
by being asked to do the obviously impossible. XP also encourages human contact among
the team, reducing the loneliness that is often at the heart of job dissatisfaction. Finally,
XP incorporates an explicit model of staff turnover. New team members are encouraged
to gradually accept more and more responsibility, and are assisted along the way by each
other and by existing programmers.

XP assumes that you see yourself as part of a team, ideally one withclear goals and a plan of
execution. XP assumes that you want to work together. XP assumes that change can be made
inexpensive using this method. XP assumes that you want to grow, to improve your skills, and

to improve your relationships. XP assumes you are willing to make changes to meet those goals.

Now I’m ready to answer the question what is XP?

 XP is giving up old, ineffective technical and social habits in favor

of new ones that work.

 XP is fully appreciating yourself for total effort today.

 XP is striving to do better tomorrow.

 XP is evaluating yourself by your contribution to the team’s

shared goals.

SSEC I.T. Page 18

 EXTREME PROGRAMMING

 XP is asking to get some of your human needs met through software development.

Extreme Programming emphasizes teamwork. Managers, customers, and developers are

all equal partners in a collaborative team. Extreme Programming implements a simple, yet
effective environment enabling teams to become highly productive. The team self-organizes
around the problem to solve it as efficiently as possible. .

Extreme Programming improves a software project in five essential ways;

communication, simplicity, feedback, respect, and courage. Extreme Programmers constantly
communicate with their customers and fellow programmers. They keep their design simple and
clean. They get feedback by testing their software starting on day one. They deliver the system to

SSEC I.T. Page 19

 EXTREME PROGRAMMING

the customers as early as possible and implement changes as suggested. Every small success
deepens their respect for the unique contributions of each and every team member. With this
foundation Extreme Programmers are able to courageously respond to changing requirements
and technology.

Extreme Programming (hereafter known as XP) is methodology of software engineering,

one of the most known and used of the ‘agile software development’ techniques. Similar to other
agile software development techniques, XP places more emphasis on adaptability than
predictability. Those who follow XP say these changes are natural and required, as it’s
inescapable and is a desirable aspect of all projects nowadays. It also has in mind four values,
with a fifth just recently added: Communication, Simplicity, Feedback, Courage, and Respect.

Building a software system requires communicating the system requirements to the

developing team. Otherwise, this can also be achieved in the form of documentation. The goal of
this principle is to give everyone in the team a shared view of the system, a view that should be
similar to those of the users of the system. Thus, XP favors collaboration of users and
programmers, simple designs, frequent verbal communication, and feedback.

It is highly encouraged to start with the simplest solution and work your way up from
there. The idea behind this is to code for today and not for tomorrow. There is a disadvantage and
an advantage to this; it is more difficult to change the system is something where to change in the
tomorrow. But at the same time, the costs of investments for future might be reduced or not
wasted if something where to change.

Feedback entails three different purposes. Feedback from the system in the form of unit
tests, or running integration tests, feedback from the customer in the form of acceptance tests
written by the users and customers, and feedback from the team when the customers come up
with new ideas, the team gives an estimate of time for it to be implemented.

Courage has several meanings in XP. One is to always design and code for today, not for
tomorrow, similar to what simplicity says. Another is to know when to throw away or discard
obsolete source code, no matter how much time was spent on it. And last but not least,
persistence.

SSEC I.T. Page 20

 EXTREME PROGRAMMING

Respect comes in many ways, but easily the most recognizable forms of them is in
respecting the other members of the team, for a programmer should never make sudden changes
that break the compilation, make the existing version fail, or otherwise delay the work of the
project.

However, XP didn’t simply start out of nowhere. Back in 1996, it was originally thought
by Kent Beck, Ward Cunningham, and Jon Refries during their payroll project on the C3
(Chrysler Comprehensive Compensation System). Kent became the leader of the project in the
aforementioned year and began to redefine the development methodology for the work. Kent
started to write a book on this methodology and then, in 1999, it was published under the name
of Extreme Programming Explained. Chrysler closed the failing project in 2000, but the
methodology was good enough to catch on in the software engineering field. As of this date,
many software-development projects still use XP as their main methodology.

In further detail, software development back in 1990 was influenced by two things:
object-oriented programming replaced procedural programming as the paradigm favored by the
industry, also, the rise of the Internet with the dot-com boom in business also made speed-to-
market a competitive business factor.

Extreme Programming Explained described XP as:

 An attempt to reconcile humanity with productivity.

 A mechanism for social change.

 A path to improvement.

 A style of development.

 A software development discipline.

SSEC I.T. Page 21

 EXTREME PROGRAMMING

The main point of XP is to reduce the cost of change. This is attained by introducing
basic values, principles and practices. This way, a system should be more flexible to change.
.

The most surprising aspect of Extreme Programming is its simple rules. Extreme
Programming is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces
make no sense, but when combined together a complete picture can be seen. The rules may seem
awkward and perhaps even naive at first, but are based on sound values and principles.

Our rules set expectations between team members but are not the end goal themselves.
You will come to realize these rules define an environment that promotes team collaboration and
empowerment, that is your goal. Once achieved productive teamwork will continue even as rules
are changed to fit your company's specific needs.

This flow chart shows how Extreme Programming's rules work together. Customers enjoy
being partners in the software process, developers actively contribute regardless of experience
level, and managers concentrate on communication and relationships. Unproductive activities
have been trimmed to reduce costs and frustration of everyone involved.

HISTORY
SSEC I.T. Page 22
 EXTREME PROGRAMMING

Extreme Programming was created by Kent Beck during his work on the Chrysler
Comprehensive Compensation System (C3) payroll project.

The Chrysler Comprehensive Compensation System (commonly referred to as 'C3') was a

project in the Chrysler Corporation to replace several payroll applications with a single system.
The new system was built using Smalltalk and GemStone. The software development techniques
invented and employed on this project are of interest in the history of software engineering. C3
has been referenced in several books on the Extreme Programming methodology. C3 was never
fully implemented and was eventually shut down.

Kent Beck is an American software engineer and the creator

of Extreme Programming and Test Driven Development. Beck was
one of the 17 original signatories of the Agile Manifesto in 2001.

Kent Beck has an M.S. degree in computer science from the

University of Oregon. He has pioneered software design patterns, the
rediscovery of Test-driven development, as well as the commercial
application of Smalltalk. Beck popularized CRC cards with Ward
Cunningham and along with Erich Gamma created the JUnit unit
testing framework.

Kent lives in Medford, Oregon where he makes goat cheese. Beck became the C3 project
leader in March 1996 and began to refine the development method used in the project and wrote
a book on the method (in October 1999, Extreme Programming Explained was published).
Chrysler cancelled the C3 project in February 2000, after the company was acquired by Daimler-
Benz.

Although Extreme Programming itself is relatively new, many of its practices have been
around for some time; the methodology, after all, takes "best practices" to extreme levels. For
example, the "practice of test-first development, planning and writing tests before each micro-
increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003).
Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his
book published in 1984.
SSEC I.T. Page 23
 EXTREME PROGRAMMING

ORIGIN

Software development in the 1990s was shaped by two major influences: internally,
object-oriented programming replaced procedural programming as the programming paradigm
favored by some in the industry; externally, the rise of the Internet and the dot-com boom
emphasized speed-to-market and company-growth as competitive business factors. Rapidly-
changing requirements demanded shorter product life-cycles, and were often incompatible with
traditional methods of software development.

The Chrysler Comprehensive Compensation System was started in order to determine the
best way to use object technologies, using the payroll systems at Chrysler as the object of
research, with Smalltalk as the language and GemStone as the data access layer. They brought in
Kent Beck, a prominent Smalltalk practitioner, to do performance tuning on the system, but his
role expanded as he noted several issues they were having with their development process. He
took this opportunity to propose and implement some changes in their practices based on his
work with his frequent collaborator, Ward Cunningham.

Beck describes the early conception of the methods: The first time I was asked to lead a
team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews.
The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this
will make a good article," asked the team to crank up all the knobs to 10 on the things I thought
were essential and leave out everything else.

Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries
thereafter acted as a coach to instill the practices as habits in the C3 team.

Ron Jeffries is one of the 3 founders of the Extreme Programming (XP) software
development methodology circa 1996, along with Kent Beck and Ward Cunningham. He was
from 1996, an XP coach on the Chrysler Comprehensive Compensation System project, which
was where XP was invented. He is an author of Extreme Programming Installed, the second book

SSEC I.T. Page 24

 EXTREME PROGRAMMING

published about XP. He has also written Extreme Programming Adventures in C#. He is one of
the 17 original signatories of the Agile Manifesto.

Information about the principles and practices behind XP was disseminated to the wider
world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various
contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted
(see agile software development). Also, XP concepts have been explained, for several years,
using a hyper-text system map on the XP website at "http://www.extremeprogramming.org" circa
1999.

Beck edited a series of books on XP, beginning with his own Extreme Programming
Explained, spreading his ideas to a much larger, yet very receptive, audience. Authors in the
series went through various aspects attending XP and its practices, even a book critical of the
practices.

CURRENT
XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of
environments radically different from its origins.

The high discipline required by the original practices often went by the wayside, causing
some of these practices that were thought too rigid to be deprecated or left undone on individual
sites. Agile development practices have not stood still, and XP is still evolving, assimilating
more lessons from experiences in the field. In the second edition of Extreme Programming
Explained, Beck added more values and practices and differentiated between primary and
corollary practices

CONCEPT

GOAL

SSEC I.T. Page 25

 EXTREME PROGRAMMING

Extreme Programming Explained describes Extreme Programming as a software

development discipline that organizes people to produce higher quality software more
productively.

In traditional system development methods (such as SSADM or the waterfall model) the
requirements for the system are determined at the beginning of the development project and often
fixed from that point on. This means that the cost of changing the requirements at a later stage (a
common feature of software engineering projects) will be high. Like other agile software
development methods, XP attempts to reduce the cost of change by having multiple short
development cycles, rather than one long one. In this doctrine changes are a natural, inescapable
and desirable aspect of software development projects, and should be planned for instead of
attempting to define a stable set of requirements.

Extreme Programming also introduces a number of basic values, principles and practices
on top of the agile programming framework.

ACTIVITIES

XP describes four basic activities that are performed within the software development
process.

CODING

The advocates of XP argue that the only truly important product of the system
development process is code - software instructions a computer can interpret. Without code,
there is no work product.

Those who practice XP say that the only important part is the code. After all, without
code you have nothing to work with. Coding has several ways to be used in reality, such as, but
not limited to, drawing diagrams that will generate code later on, scripting a web-based system,
or coding a program needed to be compiled. It can also be used to find the most suitable solution

SSEC I.T. Page 26

 EXTREME PROGRAMMING

for the problem at hand. For example, if you have multiple solutions, you can try coding them all
and then running a series of test to find out which one of them is the most optimized option.

Coding can also be used to figure out the most suitable solution. For instance, XP would
advocate that faced with several alternatives for a programming problem, one should simply code
all solutions and determine with automated tests which solution is most suitable.Coding can also
help to communicate thoughts about programming problems. A programmer dealing with a
complex programming problem and finding it hard to explain the solution to fellow programmers
might code it and use the code to demonstrate what he or she means. Code, say the proponents of
this position, is always clear and concise and cannot be interpreted in more than one way. Other
programmers can give feedback on this code by also coding their thoughts.

TESTING

One can not be certain that a function works unless one tests it. Bugs(A software bug is
the common term used to describe an error, flaw, mistake, failure, or fault in a computer program
or system that produces an incorrect or unexpected result, or causes it to behave in unintended
ways. Most bugs arise from mistakes and errors made by people in either a program's source
code or its design, and a few are caused by compilers producing incorrect code. A program that
contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said
to be buggy.) and design errors are pervasive problems in software development. Extreme
Programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can
eliminate many more flaws.

 Unit tests determine whether a given feature works as intended. A programmer

writes as many automated tests as they can think of that might "break" the code; if
all tests run successfully, then the coding is complete. Every piece of code that is
written is tested before moving on to the next feature. Unit testing is the
cornerstone of Extreme Programming, which relies on an automated unit testing
framework. This automated unit testing framework can be either third party, e.g.,

SSEC I.T. Page 27

 EXTREME PROGRAMMING

xUnit, or created within the development group.Extreme Programming uses the

creation of unit tests for test-driven development.The developer writes a unit test
that exposes either a software requirement or a defect. This test will fail because
either the requirement isn't implemented yet, or because it intentionally exposes a
defect in the existing code. Then, the developer writes the simplest code to make
the test, along with other tests, pass.Most code in a system is unit tested, but not
necessarily all paths through the code. Extreme Programming mandates a 'test
everything that can possibly break' strategy, over the traditional 'test every
execution path' method. This leads developers to develop fewer tests than classical
methods, but this isn't really a problem, more a restatement of fact, as classical
methods have rarely ever been followed methodically enough for all execution
paths to have been thoroughly tested. Extreme Programming simply recognizes
that testing is rarely exhaustive (because it is often too expensive and time-
consuming to be economically viable) and provides guidance on how to
effectively focus limited resources.

 Acceptance tests verify that the requirements as understood by the programmers

satisfy the customer's actual requirements. These occur in the exploration phase of
release planning. Acceptance testing is a term used in agile software development
methodologies, particularly Extreme Programming, referring to the functional
testing of a user story by the software development team during the
implementation phase.The customer specifies scenarios to test when a user story
has been correctly implemented. A story can have one or many acceptance tests,
whatever it takes to ensure the functionality works. Acceptance tests are black box
system tests. Each acceptance test represents some expected result from the
system. Customers are responsible for verifying the correctness of the acceptance
tests and reviewing test scores to decide which failed tests are of highest priority.
Acceptance tests are also used as regression tests prior to a production release. A
user story is not considered complete until it has passed its acceptance tests. This

SSEC I.T. Page 28

 EXTREME PROGRAMMING

means that new acceptance tests must be created for each iteration or the
development team will report zero progress.

You can never be sure of anything unless you’ve tested it. Testing is, in the long run, not
absolutely necessary; a lot of software ships without proper testing and it stills works to a certain
degree. In XP however, you can never assure a function will work unless you’ve tested it. If you
are uncertain that what you coded works, XP offers several Unit Tests, automated tests that test
the code. The programmer will try to make as many tests as possible to try and break the code. If
it stands over all, then it works. There are also Acceptance Tests, which test the code according
to what the user needs in order to see if it provides the expected results.

A "testathon" is an event when programmers meet to do collaborative test writing, a kind

of brainstorming relative to software testing.

LISTENING

Programmers must listen to what the customers need the system to do, what "business
logic" is needed. They must understand these needs well enough to give the customer feedback
about the technical aspects of how the problem might be solved, or cannot be solved.
Understanding of his or her problem. Communication between the customer and programmer is
further addressed in The Planning Game.

The function and the way the software will work are determined by the business side.
That is, it is up to the client or the user to say what the functionality of the system should be, and
the developing team has to listen to this. This, the communication between both sides is a main
part of ‘The Planning Game’, one of the core practices of XP which will be explained further on.

SSEC I.T. Page 29

 EXTREME PROGRAMMING

The main planning process within Extreme Programming is called the Planning Game.
The game is a meeting that occurs once per iteration, typically once a week. The planning
process is divided into two parts:

 Release Planning: This is focused on determining what requirements are included in

which near-term releases, and when they should be delivered. The customers and
developers are both part of this. Release Planning consists of three phases:

I. Exploration Phase: In this phase the customer will provide a short list of high-value
requirements for the system. These will be written down on user story cards.

II. Commitment Phase: Within the commitment phase business and developers will
commit themselves to the functionality that will be included and the date of the next
release.

III. Steering Phase: In the steering phase the plan can be adjusted, new requirements can
be added and/or existing requirements can be changed or removed.

 Iteration Planning: This plans the activities and tasks of the developers. In this process
the customer is not involved. Iteration Planning also consists of three phases:

I. Exploration Phase: Within this

phase the requirement will be translated to different tasks. The tasks are recorded on
task cards.

II. Commitment Phase: The tasks will be assigned to the programmers and the time
it takes to complete will be estimated.

III. Steering Phase: The tasks are performed and the end result is matched with the
original user story.

The purpose of the Planning Game is to guide the product into delivery. Instead of
predicting the exact dates of when deliverables will be needed and produced, which is difficult to
do, it aims to "steer the project" into delivery using a straightforward approach.

SSEC I.T. Page 30

 EXTREME PROGRAMMING

DESIGNING

From the point of view of simplicity, of course one could say that system development
doesn't need more than coding, testing and listening. If those activities are performed well, the
result should always be a system that works. In practice, this will not work. One can come a long
way without designing but at a given time one will get stuck. The system becomes too complex
and the dependencies within the system cease to be clear. One can avoid this by creating a design
structure that organizes the logic in the system. Good design will avoid lots of dependencies
within a system; this means that changing one part of the system will not affect other parts of the
system.

From a simple point of view, one could go as far as to say that a software development
doesn’t need anything besides coding, testing, and listening. But in practice, it tends to not be
enough. Thus, the idea behind this is to design a ‘sketch’ or design structure of how the system
will work and what it will entail. Good design allows for little dependencies, so that changing
one part of the system will not break something else.

VALUES

Extreme Programming initially recognized four values in 1999. A new value was added
in the second edition of Extreme Programming Explained. The five values are:

COMMUNICATION

Building software systems requires communicating system requirements to the

developers of the system. In formal software development methodologies, this task is
accomplished through documentation. Extreme Programming techniques can be viewed as
methods for rapidly building and disseminating institutional knowledge among members of a
development team. The goal is to give all developers a shared view of the system which matches

SSEC I.T. Page 31

 EXTREME PROGRAMMING

the view held by the users of the system. To this end, Extreme Programming favors simple
designs, common metaphors, collaboration of users and programmers, frequent verbal
communication, and feedback.

SIMPLICITY

Extreme Programming encourages starting with the simplest solution. Extra functionality
can then be added later. The difference between this approach and more conventional system
development methods is the focus on designing and coding for the needs of today instead of
those of tomorrow, next week, or next month. This is sometimes summed up as the "you ain't
gonna need it" approach. Proponents of XP acknowledge the disadvantage that this can
sometimes entail more effort tomorrow to change the system; their claim is that this is more than
compensated for by the advantage of not investing in possible future requirements that might
change before they become relevant. Coding and designing for uncertain future requirements
implies the risk of spending resources on something that might not be needed. Related to the
"communication" value, simplicity in design and coding should improve the quality of
communication. A simple design with very simple code could be easily understood by most
programmers in the team.

FEEDBACK

Within Extreme Programming, feedback relates to different dimensions of the system

development:

SSEC I.T. Page 32

 EXTREME PROGRAMMING

 Feedback from the system: by writing unit tests, or running periodic integration
tests, the programmers have direct feedback from the state of the system after
implementing changes.

 Feedback from the customer: The functional tests are written by the customer
and the testers. They will get concrete feedback about the current state of their
system. This review is planned once in every two or three weeks so the customer
can easily steer the development.

 Feedback from the team: When customers come up with new requirements in
the planning game the team directly gives an estimation of the time that it will
take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are
easily communicated by writing a unit test that proves a certain piece of code will break. The
direct feedback from the system tells programmers to recode this part. A customer is able to test
the system periodically according to the functional requirements, known as user stories.

A user story is a software system requirement formulated as one or more sentences in the
everyday or business language of the user. User stories are used with Agile software
development methodologies for the specification of requirements (together with acceptance
tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card
—to ensure that it does not grow too large. The user stories should be written by the customers
for a software project and are their main instrument to influence the development of the software.

User stories are a quick way of handling customer requirements without having to elaborate vast
formalized requirement documents and without performing overloaded administrative tasks
related to maintaining them. The intention with the user story is to be able to respond faster and
with less overhead to rapidly changing real-world requirements.

SSEC I.T. Page 33

 EXTREME PROGRAMMING

A user story is an informal statement of the requirement as long as the correspondence of

acceptance testing procedures is lacking. Before a user story is to be implemented, an appropriate
acceptance procedure must be written by the customer to ensure by testing or otherwise
determine whether the goals of the user story have been fulfilled. Some formalization finally
happens when the developer accepts the user story and the acceptance procedure as his work
specific order.

To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is

the treatment."

COURAGE

Several practices embody courage. One is the commandment to always design and code
for today and not for tomorrow. This is an effort to avoid getting bogged down in design and
requiring a lot of effort to implement anything else. Courage enables developers to feel
comfortable with refactoring their code when necessary. This means reviewing the existing
system and modifying it so that future changes can be implemented more easily. Another
example of courage is knowing when to throw code away: courage to remove source code that is
obsolete, no matter how much effort was used to create that source code. Also, courage means
persistence: A programmer might be stuck on a complex problem for an entire day, then solve
the problem quickly the next day, if only they are persistent.

RESPECT

The respect value manifests in several ways. In Extreme Programming, team members
respect each other because programmers should never commit changes that break compilation,
that make existing unit-tests fail, or that otherwise delay the work of their peers. Members
respect their work by always striving for high quality and seeking for the best design for the
solution at hand through refactoring.

SSEC I.T. Page 34

 EXTREME PROGRAMMING

Code refactoring is the process of changing a computer program's source code without
modifying its external functional behavior in order to improve some of the nonfunctional
attributes of the software. Advantages include improved code readability and reduced complexity
to improve the maintainability of the source code, as well as a more expressive internal
architecture or object model to improve extensibility.

Adopting the four earlier values leads to respect gained from others in the team. Nobody
on the team should feel unappreciated or ignored. This ensures high level of motivation and
encourages loyalty toward the team, and the goal of the project. This value is very dependent
upon the other values, and is very much oriented toward people in a team.

RULES

The first version of XP rules was proposed by Ken Hauer in XP/Agile Universe 2003. He
felt XP was defined by its rules, not its practices (which are subject to more variation and
ambiguity). He defined two categories: "Rules of Engagement" which dictate the environment in
which software development can take place effectively, and "Rules of Play" which define the
minute-by-minute activities and rules within the framework of the Rules of Engagement.

In the APSO workshop at ICSE 2008 Conference, Mehdi Mirakhorli proposed a new and
more precise and comprehensive version of the Extreme Programming Rules, more independent
of the practices, and intended to be more "agile".

RULES OF ENGAGEMENT

According to Mehdi Mirakhorli, these are:

 Business people and developers do joint work: Business people and developers must
work together daily throughout the project.

SSEC I.T. Page 35

 EXTREME PROGRAMMING

 Our highest priority is customer satisfaction: The customer must set and continuously
adjust the objectives and priorities based on estimates and other information provided by
the developers or other members of the team. Objectives are defined in terms of what not
how.

 Deliver working software frequently: Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference to the shorter time scale (timeboxing).

 Working software: Working software is the primary measure of progress.

 Global awareness: At any point, any member of the team must be able to measure the
team’s progress towards the customer’s objectives and the team reflects on how to
become more effective, then tunes and adjusts its behavior accordingly.

 The team must act as an effective social network, which means:

I. Honest communication leading to continuous learning and an emphasis on

person-to-person interaction, rather than documentation.

II. Minimal degrees of separation from what is needed by the team to make progress
and the people/resources that can meet those needs.

III. Alignment of authority and responsibility.

PRINCIPLES

The principles that form the basis of XP are based on the values just described and are
intended to foster decisions in a system development project. The principles are intended to be
more concrete than the values and more easily translated to guidance in a practical situation.

FEEDBACK

SSEC I.T. Page 36

 EXTREME PROGRAMMING

Extreme Programming sees feedback as most useful if it is done rapidly and expresses
that the time between an action and its feedback is critical to learning and making changes.
Unlike traditional system development methods, contact with the customer occurs in more
frequent iterations. The customer has clear insight into the system that is being developed. He or
she can give feedback and steer the development as needed.

Unit tests also contribute to the rapid feedback principle. When writing code, the unit test
provides direct feedback as to how the system reacts to the changes one has made. If, for
instance, the changes affect a part of the system that is not in the scope of the programmer who
made them, that programmer will not notice the flaw. There is a large chance that this bug will
appear when the system is in production.

ASSUMING SIMPLICITY

This is about treating every problem as if its solution were "extremely simple".
Traditional system development methods say to plan for the future and to code for reusability.
Extreme programming rejects these ideas.

The advocates of Extreme Programming say that making big changes all at once does not
work. Extreme Programming applies incremental changes: for example, a system might have
small releases every three weeks. When many little steps are made, the customer has more
control over the development process and the system that is being developed.

EMBRACING CHANGE

The principle of embracing change is about not working against changes but embracing
them. For instance, if at one of the iterative meetings it appears that the customer's requirements
have changed dramatically, programmers are to embrace this and plan the new requirements for
the next iteration.

SSEC I.T. Page 37

 EXTREME PROGRAMMING

EXTREME PROGRAMMING PRACTICES

Extreme Programming has been described as having 12 practices, grouped into four areas:

SSEC I.T. Page 38

 EXTREME PROGRAMMING

FINE SCALE FEEDBACK

PAIR PROGRAMMING

SSEC I.T. Page 39

 EXTREME PROGRAMMING

Pair programming means that all code is produced by two people programming on one
task on one workstation. One programmer has control over the workstation and is thinking
mostly about the coding in detail. The other programmer is more focused on the big picture, and
is continually reviewing the code that is being produced by the first programmer. Programmers
trade roles regularly.

All production in an XP project is done by two software engineers, sitting side by side in
the same computer. The logic behind this is that while one writes the code, the other reviews the
code to ensure it is optimized and correct. Some object against it, but in the long run, it seems
that pair programming is very good technique.

The pairs are not fixed: it's recommended that programmers try to mix as much as
possible, so that everyone knows what everyone is doing, and everybody can become familiar
with the whole system. This way, pair programming also can enhance team-wide
communication.

Pair programming is an agile software development technique in which two programmers

work together at one work station. One types in code while the other reviews each line of code as
it is typed in. The person typing is called the driver. The person reviewing the code is called the
observer . The two programmers switch roles frequently (possibly every 30 minutes or less).

SSEC I.T. Page 40

 EXTREME PROGRAMMING

While reviewing, the observer also considers the strategic direction of the work, coming
up with ideas for improvements and likely future problems to address. This frees the driver to
focus all of his or her attention on the "tactical" aspects of completing the current task, using the
observer as a safety net and guide.

BENEFITS

Design quality: Shorter programs, better designs, fewer bugs. Program code must be
readable to both partners, not just the driver, in order to be checked in. Pairs typically consider
more design alternatives than programmers working solo, and arrive at simpler, more-
maintainable designs, as well as catch design defects very early.

 Reduced cost of development: With bugs being a particularly expensive part of

software development, especially if they're caught late in the development
process, the large reduction in defect rate due to pair programming can
significantly reduce software development costs.

 Learning and training: Knowledge passes easily between pair programmers:

they share knowledge of the specifics of the system, and they pick up
programming techniques from each other as they work. New hires quickly pick up
the practices of the team through pairing.

 Overcoming difficult problems: Pairs often find that seemingly "impossible"

problems become easy or even quick, or at least possible, to solve when they work
together.

 Improved morale: Programmers report greater joy in their work and greater
confidence that their work is correct.

SSEC I.T. Page 41

 EXTREME PROGRAMMING

 Decreased management risk: Since knowledge of the system is shared among

programmers, there is less risk to management if one programmer leaves the team.

 Increased discipline and better time management: Programmers are less likely
to skip writing unit tests, spend time web-surfing or on personal email, or other
violations of discipline, when they are working with a pair partner. The pair
partner "keeps them honest".

 Resilient flow. Pairing leads to a different kind of flow than programming alone,
but it does lead to flow. Pairing flow happens more quickly: one programmer asks
the other, "What were we working on?" Pairing flow is also more resilient to
interruptions: one programmer deals with the interruption while the other keeps
working.

 Fewer interruptions: People are more reluctant to interrupt a pair than they are to
interrupt someone working alone.

 Decreased risk of RSI: The risk of repetitive stress injury is significantly

reduced, since each programmer is using a keyboard and mouse approximately
half the time they were before.

DRAWBACKS

 Work preference: Some developers prefer to work alone.

SSEC I.T. Page 42

 EXTREME PROGRAMMING

 Intimidation: A less experienced or less confident developer may feel intimidated

when pairing with a more experienced developer and participate less as a result.

 Tutoring cost: Experienced developers may find it tedious to tutor a less

experienced developer. Experienced developers working alone may be capable of
producing code that is clean and accurate at the outset, and the benefits of pairing
might not be worth the cost of an additional developer in some situations. This
may apply more especially when producing more trivial parts of the system.

 Egos and potential conflict: Personality conflicts can result in one or both
developers feeling awkward or uncomfortable. Differences in coding style may
result in conflict.

 Cost: There are varying opinions as to whether two developers can be as

productive when working together as when working separately .

SCIENTIFIC STUDIES

According to The Economist,

"Laurie Williams of the University of Utah in Salt Lake City has shown that paired
programmers are only 15% slower than two independent individual programmers, but produce
15% fewer bugs. (N.B.: The original study showed that 'error-free' code went from 70% to 85%;
it may be more intuitive to call this a 50% decrease of errors, from 30% to 15%.) Since testing
and debugging are often many times more costly than initial programming, this is an impressive
result."

The Williams et al. 2000 study showed an improvement in correctness of around 15%
and 20 to 40% decrease in time, but between a 15 and 60% increase in effort. Williams et al.

SSEC I.T. Page 43

 EXTREME PROGRAMMING

2000 also cites an earlier study (Nosek 1998) which also had a 40% decrease in time for a 60%
increase in effort.

A study (Lui 2006) presents a rigorous scientific experiment in which novice–novice

pairs against novice solos experience significantly greater productivity gains than expert–expert
pairs against expert solos.

A larger recent study (Arisholm et al. 2007) had 48% increase in correctness for complex
systems, but no significant difference in time, whilst simple systems had 20% decrease in time,
but no significant difference in correctness. Overall there was no general reduction in time or
increase in correctness, but an overall 84% increase in effort.

Lui, Chan, and Nosek (2008) shows that pair programming outperforms for design tasks.

REMOTE PAIR PROGRAMMING

Remote pair programming, also known as virtual pair programming or distributed pair
programming, is the practice of pair programming where the two programmers comprising the
pair are in different locations, working via a collaborative real-time editor, shared desktop, or a
remote pair programming IDE plugin.

Remote pair programming might be useful to do pair programming with offshore teams
or in open source projects with distributed contributors.

Some teams have tried VNC and RealVNC with each programmer using their own
computer. OtherS use the multi-display mode (-x) of the text-based GNU screen. Apple Inc.
OSX has a built-in Screen Sharing application.

Also of notice, IDEs like Eclipse and NetBeans offer their own solutions. For NetBeans
there is the The NetBeans Collaboration Project and for Eclipse, the Eclipse Communication
Framework comes with the Cola plugin, another option is Saros. Other alternatives for product
such as Visual Studio are wave-vs.net commercial or free Version Add-In, able to enable Pair
Programming for Visual Studio, (internally relays on Google Wave Federation Protocol to enable
collaborative editing), or beWeeVee for Visual Studio, still in concept phase. As for Cola, two
videos are available. A tech talk on the algorithmic internals of Cola, given at the Googleplex in
SSEC I.T. Page 44
 EXTREME PROGRAMMING

June 2008, has been made available on Google's YouTube tech talks channel. A Cola demo is
available in HD via vimeo.

PING PONG PAIR PROGRAMMING

Some agile teams use a different style of pair programming called "ping pong pair
programming". In this pattern, documented as early as 2003 on the c2.com wiki, the observer
writes a failing unit test, the driver modifies the code to pass the unit test(s), the observer writes a
new unit test, and so on. This loop continues as long as the observer is able to write failing unit
tests. The technique can result in the driver role switching as often as a few minutes or less.

PLANNING GAME

The main planning process within Extreme Programming is called the Planning Game.
The game is a meeting that occurs once per iteration, typically once a week. The planning
process is divided into two parts:

 Release Planning: This is focused on determining what requirements are included in

which near-term releases, and when they should be delivered. The customers and
developers are both part of this. Release Planning consists of three phases:

I. Exploration Phase: In this phase the customer will provide a short list of high-value
requirements for the system. These will be written down on user story cards.

SSEC I.T. Page 45

 EXTREME PROGRAMMING

II. Commitment Phase: Within the commitment phase business and developers will
commit themselves to the functionality that will be included and the date of the
next release.

III. Steering Phase: In the steering phase the plan can be adjusted, new requirements can
be added and/or existing requirements can be changed or removed.

 Iteration Planning: This plans the activities and tasks of the developers. In this process
the customer is not involved. Iteration Planning also consists of three phases:

I. Exploration Phase: Within this phase the requirement will be translated to

different tasks. The tasks are recorded on task cards.

II. Commitment Phase: The tasks will be assigned to the programmers and the time
it takes to complete will be estimated.

III. Steering Phase: The tasks are performed and the end result is matched with the
original user story.

The purpose of the Planning Game is to guide the product into delivery. Instead of
predicting the exact dates of when deliverables will be needed and produced, which is difficult to
do, it aims to "steer the project" into delivery using a straightforward approach

XP has two main questions or key concerns; predicting what will be done and by when,
and what to do next. This is to steer the project in the right direction instead of just doing what
comes to mind so that the system is better optimized and the team can work better.

RELEASE PLANNING

EXPLORATION PHASE

SSEC I.T. Page 46

 EXTREME PROGRAMMING

This is an iterative process of gathering requirements and estimating the work impact of
each of those requirements.

 Write a Story: Business has come with a problem; during a meeting,

development will try to define this problem and get requirements. Based on the
business problem, a story (user story) has to be written. This is done by business,
where they point out what they want a part of the system to do. It is important that
development has no influence on this story. The story is written on a user story
card.

 Estimate a Story: Development estimates how long it will take to implement the
work implied by the story card. Development can also create spike solutions to
analyze or solve the problem. These solutions are used for estimation and
discarded once everyone gets clear visualization of the problem. Again, this may
not influence the business requirements.

 Split a Story: Every design critical complexity has to be addressed before starting
the iteration planning. If development isn't able to estimate the story, it needs to be
split up and written again.

When business cannot come up with any more requirements, one proceeds to the
commitment phase.

COMMITMENT PHASE

This phase involves the determination of costs, benefits, and schedule impact. It has four
components:

 Sort by Value: Business sorts the user stories by Business Value.

 Sort by Risk: Development sorts the stories by risk.

 Set Velocity: Development determines at what speed they can perform the
project.

SSEC I.T. Page 47

 EXTREME PROGRAMMING

 Choose scope: The user stories that will be finished in the next release will be
picked. Based on the user stories the release date is determined.

Sort by value

The business side sorts the user stories by business value. They will arrange them into
three piles:

 Critical: stories without which the system cannot function or has no meaning.

 Significant Business Value: Non-critical user stories that have significant

business value.

 Nice to have: User stories that do not have significant business value.

Sort by risk

The developers sort the user stories by risk. They also categorize into three piles: low,
medium and high risk user stories. The following is an example of an approach to this:

 Determine Risk Index: Give each user story an index from 0 to 2 on each of the
following factors:

• Completeness (do we know all of the story details?)

I. Complete (0)

II. Incomplete (1)

III. Unknown (2)

• Volatility (is it likely to change?)

I. low (0)

II. medium (1)

SSEC I.T. Page 48

 EXTREME PROGRAMMING

III. high (2)

• Complexity (how hard is it to build?)

I. simple (0)

II. standard (1)

III. complex (2)

All indexes for a user story are added, assigning the user stories a risk index of low (0–1),
medium (2–4), or high (5–6).

STEERING PHASE

Within the steering phase the programmers and business people can "steer" the process.
That is to say, they can make changes. Individual user stories, or relative priorities of different
user stories, might change; estimates might prove wrong. This is the chance to adjust the plan
accordingly.

ITERATION PLANNING

EXPLORATION PHASE

The exploration phase of the iteration planning is about creating tasks and estimating
their implementation time.

 Translate the requirement to tasks: Place on task cards.

 Combine/Split task: If the programmer cannot estimate the task because it is too
small or too big, the programmer will need to combine or split the task.

 Estimate task: Estimate the time it will take to implement the task.

SSEC I.T. Page 49

 EXTREME PROGRAMMING

COMMITMENT PHASE

Within the commitment phase of the iteration planning programmers are assigned tasks
that reference the different user stories.

 A programmer accepts a task: Each programmer picks a task for which he or

she takes responsibility.

 Programmer estimates the task: Because the programmer is now responsible for
the task, he or she should give the eventual estimation of the task.

 Set load factor: The load factor represents the ideal amount of hands-on
development time per programmer within one iteration. For example, in a 40-hour
week, with 5 hours dedicated to meetings, this would be no more than 35 hours.

 Balancing: When all programmers within the team have been assigned tasks, a
comparison is made between the estimated time of the tasks and the load factor.
Then the tasks are balanced out among the programmers. If a programmer is
overcommitted, other programmers must take over some of his or her tasks and
vice versa.

STEERING PHASE

The implementation of the tasks is done during the steering phase of the iteration
planning.

 Get a task card: The programmer gets the task card for one of the tasks to which
he or she has committed.

 Find a Partner: The programmer will implement this task along with another
programmer. This is further discussed in the practice Pair Programming.

 Design the task: If needed, the programmers will design the functionality of the
task.

SSEC I.T. Page 50

 EXTREME PROGRAMMING

 Write unit test: Before the programmers start coding the functionality they first
write automated tests. This is further discussed in the practice Unit Testing.

 Write code: The programmers start to code.

 Run test: The unit tests are run to test the code.

 Refactor: Remove any code smells from the code.

 Run Functional test: Functional tests (based on the requirements in the

associated user story and task card) are run.

TEST DRIVEN DEVELOPMENT

Unit tests are automated tests that test the functionality of pieces of the code (e.g. classes,
methods). Within XP, unit tests are written before the eventual code is coded. This approach is
intended to stimulate the programmer to think about conditions in which his or her code could
fail. XP says that the programmer is finished with a certain piece of code when he or she cannot
come up with any further condition on which the code may fail.

XP runs with feedback. In other words, XP almost depends on feedback. And good
feedback requires good testing, so the idea behind TDD is to run periodic tests in periodic cycles
to make sure everything is perfect.

WHOLE TEAM

Within XP, the "customer" is not the one who pays the bill, but the one who really uses
the system. XP says that the customer should be on hand at all times and available for questions.
For instance, the team developing a financial administration system should include a financial
administrator.

: All the team, engineers and the customer, sit together to discuss requirements, priorities
and steer the project overall.

SSEC I.T. Page 51

 EXTREME PROGRAMMING

CONTINUOUS PROCESS

CONTINUOUS INTEGRATION

The development team should always be working on the latest version of the software.
Since different team members may have versions saved locally with various changes and
improvements, they should try to upload their current version to the code repository every few
hours, or when a significant break presents itself. Continuous integration will avoid delays later
on in the project cycle, caused by integration problems.

XP teams keep the system fully integrated at all times. XP teams build the system
multiples times a day, contrary to the usual daily build (They even go as a far as saying daily
builds are for wimps!).

DESIGN IMPROVEMENT

Because XP doctrine advocates programming only what is needed today, and

implementing it as simply as possible, at times this may result in a system that is stuck. One of
the symptoms of this is the need for dual (or multiple) maintenance: functional changes start
requiring changes to multiple copies of the same (or similar) code. Another symptom is that
changes in one part of the code affect lots of other parts. XP doctrine says that when this occurs,
the system is telling you to refactor your code by changing the architecture, making it simpler
and more generic.
SSEC I.T. Page 52
 EXTREME PROGRAMMING

XP uses a process of continuous design called Refactoring. This process focuses of

removing repeated pieces of code and instead adding to the cohesion of the system while
lowering the coupling. Two things recognized as the hallmarks of well-designed code.

SMALL RELEASES

The delivery of the software is done via frequent releases of live functionality creating
concrete value. The small releases help the customer to gain confidence in the progress of the
project. This helps maintain the concept of the whole team as the customer can now come up
with his suggestions on the project based on real experience.

: The XP team practices small releases chosen by the customer. They also release to their
end-users frequently.

SHARED UNDERSTANDING

CODING STANDARD

Coding standard is an agreed upon set of rules that the entire development team agree to
adhere to throughout the project. The standard specifies a consistent style and format for source
code, within the chosen programming language, as well as various programming constructs and
patterns that should be avoided in order to reduce the probability of defects. The coding standard
may be a standard conventions specified by the language vendor (e.g. The Code Conventions for
the Java Programming Language, recommended by Sun), or custom defined by the development
team.

XP teams follow a very thorough coding standard so that the program looks like it was
written by a single individual. The specifics of the standard are not important; what’s important
is that everything looks similar in the sake of collective ownership.

SSEC I.T. Page 53

 EXTREME PROGRAMMING

COLLECTIVE CODE OWNERSHIP

Collective code ownership means that everyone is responsible for all the code; this, in
turn, means that everybody is allowed to change any part of the code. Pair programming
contributes to this practice: by working in different pairs, all the programmers get to see all the
parts of the code. A major advantage claimed for collective ownership is that it speeds up the
development process, because if an error occurs in the code any programmer may fix it.

By giving every programmer the right to change the code, there is risk of errors being
introduced by programmers who think they know what they are doing, but do not foresee certain
dependencies. Sufficiently well defined unit tests address this problem: if unforeseen
dependencies create errors, then when unit tests are run, they will show failures.

Since a project of XP belongs to everyone in the team, everyone can make changes to any
part of the code so that it works for the best. In systems built by individual persons, if someone
discovers a missing function that shouldn’t go in his code, it’s hard to get the owner of the
correct code to add it, leading to bad cohesion and often repeated pieces of code.

SIMPLE DESIGN

Programmers should take a "simple is best" approach to software design. Whenever a

new piece of code is written, the author should ask themselves 'is there a simpler way to
introduce the same functionality?'. If the answer is yes, the simpler course should be chosen.
Refactoring should also be used, to make complex code simpler.

XP teams build software under a simple design. Through programmer testing and design
improvement, they keep the system that way: Simple.

SSEC I.T. Page 54

 EXTREME PROGRAMMING

SYSTEM METAPHOR

The system metaphor is a story that everyone - customers, programmers, and managers -
can tell about how the system works. It's a naming concept for classes and methods that should
make it easy for a team member to guess the functionality of a particular class/method, from its
name only. For example a library system may create loan_records(class) for borrowers(class),
and if the item were to become overdue it may perform a make_overdue operation on a catalogue
(class). For each class or operation the functionality is obvious to the entire team.

The SM is the way the team envisions how the system will work. If a sufficiently poetic
metaphor fails to come up, XP teams can fall back to a common system of names for the sake of
understanding what this vision or idea is.

PROGRAMMER WELFARE

SUSTAINABLE PACE

The concept is that programmers or software developers should not work more than 40
hour weeks, and if there is overtime one week, that the next week should not include more
overtime. Since the development cycles are short cycles of continuous integration, and full
development (release) cycles are more frequent, the projects in XP do not follow the typical
crunch time that other projects require (requiring overtime).

Also, included in this concept is that people perform best and most creatively if they are
rested.

A key enabler to achieve sustainable pace is frequent code-merge and always executable
& test covered high quality code. The constant refactoring way of working enforces team
members with fresh and alert minds. The intense collaborative way of working within the team
drives a need to recharge over weekends.

SSEC I.T. Page 55

 EXTREME PROGRAMMING

XP teams work for a long time. This means they learn to work overtime when it is
deemed effective and in a way to maximize productivity instead of simply cramming code into
the system to finish faster. “XP teams are in it to win, not to die.”

Well-tested, continuously integrated, frequently deployed code and environments also

minimize the frequency of unexpected production problems and outages, and the associated
after-hours nights and weekends work that is required.

XP will always (for the time being at least, unless something better arises) remain as a
sensible choice for some projects. Projects that are, or look suited for the use of XP are, but not
limited to:

 Those that involve new or prototype technology.

 Are research projects.

 Are small and easily managed.

Projects that should be considered under a different methodology other than XP are, but
not limited to:

 Those that involve stable technology.

 Involve mission critical or safety critical systems.

 Are large projects that might overwhelm communication mechanisms.

“Extreme Programming is a discipline of software development based on values of

simplicity, communication, feedback, and courage. It works by bringing the whole team together
in the presence of simple practices, with enough feedback to enable the team to see where they
are and to tune the practices to their unique situation.”

SSEC I.T. Page 56

 EXTREME PROGRAMMING

CODING

 The customer is always available

 Code the Unit test first

 Only one pair integrates code at a time

 Leave Optimization till last

 No Overtime

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 before the bug is addressed (a bug is not an
error in logic, it is a test you forgot to write)

 Acceptance tests are run often and the results are published

SSEC I.T. Page 57

 EXTREME PROGRAMMING

EXTREME PROGRAMMING FROM AN ENGINEERING

ECONOMICS VIEWPOINT
We use the concept of net present value to study for which project settings a lightweight
programming paradigm such as Extreme Programming can be an advantage over a conventional
development process. If the project is small to medium scale, the product must be of high quality,
and time to market is the decisive factor, Extreme Programming can be the right paradigm to
choose.

We use the concept of net present value to study for which project settings a lightweight
programming paradigm such as Extreme Programming can be an advantage over a conventional
development process. If the project is small to medium scale, the product must be of high quality,
and time to market is the decisive factor, Extreme Programming can be the right paradigm to
choose.

In this paper, we study XP from an economics point of view. We analyze the cost and
benefit of XP for a sample software project under different settings, systematically varying key
project parameters which are influenced when using XP techniques. In the XP community, the
techniques of XP are considered to be most beneficial if the requirements are unstable and time
to market is a decisive factor. Therefore, we use the discount rate in the formula for a project’s
net present value to explicitly take into account the impact of time to market.

`Extreme Programming breaks with a number of traditional software engineering

practices [1, 2] . The source code is the main documentation; the rational is that writing
documenttation slows down the developers and is neglected anyway. There is no specification;
executable test cases which are written before the code is developed serve as a substitute (test-
first ). There is no separate design or testing phase; design, implementation, and testing go
together in small

increments. Designing for change is explicitly prohibited; only the simplest possible design
satisfying the most important set of features is chosen. However, XP prescribes a combination of
special practices instead. All programming tasks must be performed by pairs of programmers
SSEC I.T. Page 58
 EXTREME PROGRAMMING

using one display, keyboard, and mouse. The test cases must be re- run continuously during
development. The code must be occasionally re-structured while retaining its functionality

(refactoring ). For more details on XP practices and typical difficulties when implementing XP.

From the project economics point of view, the most important practices of XP are pair
programming and test-first. Since developers team up to work on the same task, personnel cost
basically is doubled. The main claim of XP is that the increased cost is more than outweighted by
three factors :

• A pair of programmers has a higher development speed than a single programmer.

• Continuously checking the code against the test cases improves the quality of the code.

• The code produced by a pair of programmers has a reduced defect rate as compared to a
single programmer.

Two studies provide empirical evidence for the advantages of pair programming [3, 8] . A
possible explanation for a reduction in the defect rate is that pair programming leads to an
ongoing review of the program code by the second developer, and that the two developers can
readily share their ideas. The studies also provide some quantitative figures. The
PairSpeedAdvantage of a pair of programmers over a single programmer is claimed to be 29
percent on average [8] . The PairDefectAdvantage of a pair of programmers over a single
programmer is claimed to be 15 percent on average [3] .

ECONOMIC MODELLING

To compare XP with conventional development, we use the concept of net present value. The net
present value of a project [4, 5] is defined as

SSEC I.T. Page 59

 EXTREME PROGRAMMING

Since in our study time to market is assumed to be the decisive factor, a delay in the project’s
completion time will lead to a loss of market share, thus drastically decreasing the value of the
whole project. We account for time to market by choosing successively higher values for the
DiscountRate in the formula for the net present value. The Asset Value is assumed fixed. The XP
development practices have a mixed impact on the net present value of a project, as we shall see

shortly.

DEVELOPMENT TIME

Figures for the productivity of a developer range between 300 and 350 lines of code per month,
including design and coding, but excluding testing. For conventional projects, the development
time is

The time needed for quality assurance is special here: it’s the time needed to equalize the defect
rate advantage which XP has over the conventional process, see the next subsection. For an XP
project, no additional time for quality assurance is required, but pair programming must be taken

into account :

SSEC I.T. Page 60

 EXTREME PROGRAMMING

For both conventional and XP projects we implicitly make the simplifying assumption that the
productivity of the developers, respectively, programmer pairs, adds up; we do not take into
account any increase in the team communication overhead as the team size increases.

QUALITY ASSURANCE

A programmer typically inserts 100 defects per thousand lines of code . A good conventional
software process eliminates up to 70 percent of these defects . Therefore, using conventional
development there are :

defects left in the software after coding. In contrast, XP claims to lead to an improved defect rate.
In that case, the conventional project must make up for the quality difference of

SSEC I.T. Page 61

 EXTREME PROGRAMMING

defects in a separate quality assurance phase before entering the market. With XP, no separate
quality assurance phase is required.

The length of the quality assurance phase for the conventional process depends on the time
needed to remove a single defect :

DEVELOPMENT COST

For simplicity, the development cost is assumed to consist just of the salaries for the developers
and the project leader :

The formula is the same for conventional and XP project

RESULTS

SSEC I.T. Page 62

 EXTREME PROGRAMMING

SAMPLE PROJECT

To study the cost and benefit of XP, we compute the net present value of a hypothetical sample
project under different settings. The fixed parameters of the sample project areas follows :

 The ProductSize is 16, 800 lines of code.

 The DeveloperSalary is 50, 000 dollars per year.

 The ProjectLeaderSalary is 60, 000 dollars per year.

 The AssetValue of the software is 1, 000, 000 dollars.

There also are some project parameters which we vary sysematically in the study. They are
summarized in Table 1.

We visualize the difference between the net present value of the conventional project and the net
present value of the XP project using different scales of grey:

SSEC I.T. Page 63

 EXTREME PROGRAMMING

For fixed DefectRemovalTime and DiscountRate, the difference between XP and the
conventional project is visualized as a “checkboard” as the parameters PairSpeedAdvantage

and PairDefectAdvantage vary:

FOUR PAIRS

Assume that the number of developers available for the project is bounded by eight. In that case,
XP can run the project with four pairs only. The difference between the net present value of the
conventional project and the net present value of the XP project is visualized in Figure 1.

SSEC I.T. Page 64

 EXTREME PROGRAMMING

Pair programming will lead to such an increase in development time that – even for high
discount rates and high eefect removal times – the net present value of the conventional project is
larger than the net present value of the XP project. The reason is that only four tasks can be
worked on at the same time in the XP project, as compared to eight tasks in the conventional
project. This disadvantage is not balanced by the speed advantage that a programmer pair has

over a single programmer, nor by the defect rate advantage of programmer pairs.

For example, even when assuming that the discount rate is 75 percent per year, the time
needed to remove a defect is 15 hours, and the optimistic figures given in the literature for the
pair speed advantage (30 percent) and the pair defect advantage (15 percent) actually hold, the
value of the XP project is 34 percent smaller than the value of the conventional project, see the
field with the solid

dot in Figure 1.

EIGHT PAIRS

On the other hand, assume that there is a pool of developers available who could be
added to the project, but that it does not make sense to subdivide the tasks in the project any
further due to the size and structure of the project. In that case, the project leader might choose to
SSEC I.T. Page 65
 EXTREME PROGRAMMING

run the project using XP with eight pairs instead of only four pairs, doubling the personnel as
compared to the conventional project. The difference between the net present value of the
conventional project with eight developers and the net present value of the XP project with
sixteen developers (eight pairs) is visualized in Figure 2.

Despite the increased personnel cost, for high discount rates and high defect removal
times the net present value of the XP project is larger than the net present value of the
conventional project. The reason is that the speed advantage and the defect rate advantage of
programmer pairs come into full play. As a result, the increase in personnel cost is outweighted
by the gain in market share. For example, when assuming that the discount rate is 75 percent per
SSEC I.T. Page 66
 EXTREME PROGRAMMING

year, the time needed to remove a defect is 15 hours, the pair speed advantage is 30 percent, and
the pair defect advantage is 15 percent, the value of the XP project is about 6 percent higher than
the value of the conventional project, see the field with the solid dot in Figure 2.

The conclusions to be drawn from the results of the computations are clear. As long as
there is a good way to assign tasks to additional developers, using XP does not provide an
advantage. On the other hand, if the size and structure of a project are such that the tasks can not
be reasonably subdivided any further, adding developers in such a way that they team up to pairs
can reduce the development time and thus increase the value of the project despite the increased

cost for personnel. This holds especially if time to market is the decisive factor. The smaller the
market pressure, the more the potential advantages of XP diminish.

SSEC I.T. Page 67

 EXTREME PROGRAMMING

DISTRIBUTED EXTREME PROGRAMMING

One of the key requirements of eXtreme Programming (XP) is strong and effective
communication between the team members. To enable this strong level of communication among
team members, XP emphasizes the need to have the team members physically located close to
each other. However, for various reasons, it may not be feasible to have team members
physically located close to each other.

To address these situations, we propose a crosscutting idea called “Distributed eXtreme

Programming” (DXP), which inherits the merits of XP and applies it in a distributed team
environment. Our experiences show that DXP can be both effective and rewarding in projects
whose teams are geographically distributed.

Extreme Programming (XP) is a lightweight methodology that has gained increasing

acceptance and popularity in the software community. XP promotes a discipline of software
development based on principles of simplicity, communication, feedback, and courage. It is
designed for use with small teams that need to develop software quickly and in an environment
of rapidly changing requirements. XP consists of twelve practices, which are Planning Game,
Small Releases, Metaphor, Simple Design, Testing, Refactoring, Pair Programming, Collective
Ownership, Continuous Integration, 40-hour Week, On-Site Customer, and Coding Standard. A
careful analysis of these XP practices reveals certain key assumptions made by XP:

SSEC I.T. Page 68

 EXTREME PROGRAMMING

XP advocates a strong level of communication among team members. Among all of the
XP practices, one of the key practices is pair programming. Pair programming is not just one
person programming and the other observing. Instead, it is a dialog between people trying to
simultaneously design, program, analyze, test, and understand together how to program better. It
is a conversation at many levels, assisted and focused on a computer . Therefore, a key
assumption made by XP is strong and effective communication between the team members,
enabling the diffusion of know-how and expertise throughout the group. To enable this strong
level of communication among team members, the literature on XP emphasizes that it is
important to have the team members physically located close to each other. Ideally, the team
members should be all in one room. The reason for this is to enhance the communication among
team members through incidental over-hearing of conversations and to minimize any hesitation
that the team members might have in communicating to each other.

Close Customer Involvement: Another important practice of XP requires close customer

involvement in the entire development cycle. Different from traditional methodology, XP
stresses the role of an on-site customer and thus recommends having a representative of the

customer working with the team all the time. The customer or one of its representatives thus
becomes an integral part of the team. Therefore, a proper communication channel between the
customer and the rest of the team can easily be realized if the customer is physically located on-
site. Thus, close physical proximity of team members along with close customer involvement are
key assumptions made by XP.

However, if physical proximity of team members or the customer is not feasible or

desirable, will XP lose its effectiveness? In this paper, we show how XP can be applied to
software development and teamwork in a distributed team environment. Our crosscutting idea is
whether it is really necessary for the team members to be physically located next to each
otherdescribes our extension to traditional XP that we call Distributed eXtreme Programming
(DXP).

SSEC I.T. Page 69

 EXTREME PROGRAMMING

We describe the assumptions made by DXP, the rationale behind DXP, the challenges in
DXP and finally how to address these challenges. In we present our experience report on using
DXP and in we present our conclusions.

DISTRIBUTED EXTREME PROGRAMMING

We define Distributed eXtreme Programming (DXP) as eXtreme Programming with certain

relaxations on the requirements of close physical proximity of the team members. DXP applies
XP principles in a distributed and mobile team environment. In DXP, team members can be

arbitrarily far apart as well as highly mobile. Some ideas towards DXP have already been
mentioned at the "eXtreme Programming and Flexible Processes in Software Engineering
XP2000" conference. DXP addresses all aspects of XP although to varying degrees. There are in
general certain things that are irrelevant to the locality of the team, while others are totally bound
to the fact that the team members are colocated.

The following Table summarizes some of the aspects that are relevant to DXP and some that are
not.

SSEC I.T. Page 70

 EXTREME PROGRAMMING

From this table it becomes clear that for effective DXP, we need to address the practices of
Planning Game, Pair Programming, Continuous-Integration, and On-Site Customer in a
distributed team environment. We will see how these practices are addressed. Note that we
consider Refactoring, by itself, to not require co-location. The actual implementation of a
refactor relies on Pair Programming. However, deciding whether it is needed or its high level
form is separate. Even more concrete design tasks may best be initiated alone ; we consider this
to be part of the Refactoring, while the implementation tasks fall under Pair Programming.

DXP ASSUMPTIONS

SSEC I.T. Page 71

 EXTREME PROGRAMMING

To be effective, DXP assumes existence of certain conditions as well as availability of several

tools andtechnologies. Beyond the assumptions of XP, like speaking a common language and
general openness, DXP assumes:

 Connectivity: Some form of connectivity needs to exist between the team members. If
communication is performed across long distances, it is assumed that the Internet is used
as communication media. For company-local communication an intranet can be used.

 E-Mail: The ubiquitous availability of e-mail makes it a key enabling technology for
DXP. It can be used as a convenient means to exchange information as well to schedule
any DXP sessions.

 Configuration Management: Effective management of programming artifacts mandates

the use of some kind of configuration management tool. This in turn serves as a key
enabler for collective ownership.

 Application Sharing: To apply XP practices in a distributed environment, some form of

application or desktop sharing software needs to be available to the team.

 Video Conferencing: For effective communication using audio and video among distant
team members, some kind of video conferencing support is needed.

 Familiarity: We expect that DXP can succeed only when team members know each
other well, and can view it as an extension of their prior work arrangements.

WHY DXP?

SSEC I.T. Page 72

 EXTREME PROGRAMMING

XP stresses the need for close physical proximity of team members. However, circumstances
may prevent a team from working in close physical proximity, thus mandating the need for using
DXP. A company or a project may therefore be forced to adopt DXP for the following reasons:

 Constrained by situation: A company or a project may have little choice due to

existing physical distribution of development teams. Many projects are sanctioned
with teams residing in different locations, sometimes across the globe.

 Individual Constraints: An individual may not be able to work at his/her

company's location due to personal reasons and may therefore choose to work off-
site. It thus becomes important that the individual continues to stay part of the
development activities even while being physically separated.

Even if a company or a project is not constrained by circumstances, it may still choose to

adopt DXP. This is because, in addition to maintaining the benefits of XP practices, DXP offers
some additional benefits, including:

 Cost: A growing trend in the software industry is to outsource all or part of a

software project due to cost. It is often much cheaper to get software developed in
some countries such as India or China. As a result, several projects get distributed
across two or more countries.

 Convenient Customer Involvement: DXP makes it easier to involve the

customer, even if he/she is unable to be at the development site. With traditional
XP, the customer would have to stay on-site. This may not be desirable to the
customer since it may cut the customer off from his/her company. In DXP,
however, this problem does not arise because the customer need not be on-site and
can simply be available to the development team through videoconferencing.

SSEC I.T. Page 73

 EXTREME PROGRAMMING

 Mobility: In many organizations, some team members need to travel frequently to

maintain customer contacts, to attend conferences, or for some other reasons.
DXP offers a smooth integration of mobile team members. Mobile team member
can stay connected with the rest of the team using some form of mobile
equipment, such as a notebook with a small camera and an ISDN or a dial-up
connection. The team members can then participate in the development activities
for part of the day or even for just a few hours.

DXP thus addresses both circumstantial constraints of companies and projects as well as
offers tangible benefits in addition to those offered by XP.

CHALLENGES IN DXP

In relaxing the requirement of XP of close physical proximity, DXP faces several challenges.

 Communication: An important aspect of communication for humans is to

know how the other person reacts to what one says. To judge a reaction,
typically a person would read this information from body gestures, the
face, and the voice of the other person. In DXP, since the two people are
not physically next to each other, how can one receive this information?

 Coordination: When two or more team members working together on a

project are in two different physical locations, coordination among them
becomes a challenge. This can include synchronizing availability,
adjusting for time differences, and coordinating distribution as well as
integration of activities. In addition, document/application sharing among
the team members can also prove to be a challenge.

SSEC I.T. Page 74

 EXTREME PROGRAMMING

 Infrastructure: Both communication and coordination among team

members in DXP depend heavily on the infrastructure. This includes the
available hardware and software as well as the bandwidth of the
connecting network. A poor infrastructure can make it very difficult to
make up for the close physical proximity that can be missing in DXP.

 Availability: Distributed team members may be available at different

times. Some of them might be working on multiple projects and hence be
restricted by time. Others might be constrained by personal limitations. In
addition, the availability of distributed team members can also be affected
by different time zones.

 Management: The manager of the team needs to have ahigh degree of

trust in his/her subordinates if they are often remote. Direct managerial
control over distant subordinates can be difficult to execute and therefore
new strategies may need to be defined.

ADDRESSING THE CHALLENGES/SOLUTION

DXP offers many challenges. However, each of these challenges can be addressed and in most
cases overcome.

SSEC I.T. Page 75

 EXTREME PROGRAMMING

 Communication: Given a close-knit team, good communication can take place

among them without requiring physical collocation. For example, assuming you
know the other person pretty well, a little video picture of your partner might be
sufficient to be able to tell what he/she is thinking and how he/she reacts to your
comment. The team members can use many different forms of communication to
bridge the physical distance. For example, they could convene a video or a phone
conference, or could send each other e-mail. In addition, actual meetings could be
convened periodically to enhance inter-personal relationships among team
members thus making remote co-operation easier. When deciding upon a
particular form of communication, many different factors need to be considered.
These include cost of equipment and its usage, travel costs, cost of time, available
bandwidth and the effectiveness of the particular form of communication with
respect to the tasks that need to be performed. Remote communication and
cooperation can be greatly improved by the ability of sharing documents. With
web technologies becoming more and more inexpensive and therefore popular,
new ways of communication are now available that allow close involvement
among team members across intranet or Internet via videoconferencing and
application sharing.

 Coordination: Proper coordination of activities among distributed team members

requires a good bit of planning. However, making extensive use of different lines
of communication can facilitate this. For example, two members in different
locations could exchange daily e-mails containing their schedules for the day.
They could then assign certain slots within the day for working on a project. In
doing so, they would also need to take into account any time differences that may
exist.

 Infrastructure: The availability of the necessary technical infrastructure is also

very important. All team members must have adequate software and hardware.

SSEC I.T. Page 76

 EXTREME PROGRAMMING

Important factors in choosing the software are ease of use, interoperability with
other tools, and availability on different platforms. The hardware should be
chosen with particular care as well; in fact, each developer will needthe power of
a classical development workstation, combined with the features of a multimedia
workstation.

 Availability: The DXP team needs to formulate rules and guidelines in order to
ensure availability of the team members. The general XP spirit of not denying
help to anyone asking for it should be leveraged to being available for remote
communication. A daily or a weekly schedule of availability of each team
member should be made available and easily accessible to all the team members.
Pair programming sessions or testing sessions should then be scheduled based on
the availability of the team members and to allow maximum amount of
knowledge diffusion to take place.

 Management: Project leaders and the upper management need to learn how to
handle distributed teams. In particular, project leaders need to learn how to
manage team members who are at different locations. This can include requiring
daily or weekly reports from all the team members, whether local or remote. It can
also include giving regular feedback to team members to give them a feel that
they are connected and hence an integral part of the team. In addition, regular
team events can help build trust and motivation among all the team members.

ADDRESSING XP PRACTICES & VALUES IN DXP

In addressing the challenges of DXP it is important that the practices and values of DXP are not
violated.Only four XP practices get affected in a distributed team environment Planning Game,
Pair programming, Continuous Integration, and On-site Customer. This section examines each of

SSEC I.T. Page 77

 EXTREME PROGRAMMING

these practices in the light of DXP and proposes possible solutions that can be applied to keep
DXP within the realms of XP practices.

 Planning Game - For the planning game with the customer being remote, video
conferencing and application sharing software support is needed. For example,
application sharing can be used to write the story cards. Ideally more than two
participants should be supported. Though this is possible with certain solutions, such as
CUseeMe , most video conferencing software support only one pair of participants.

 Pair Programming - For pair programming between team members in different

locations, Remote Pair Programming (RPP) should be used. This requires video
conferencing and application sharing support, to share the Integrated Development
Environment (IDE).

 Continuous Integration - Because a remote team member cannot move to a separate

integration machine, a workaround needs to be defined. If one team member is working at
the central team site, he/she can invite the other remote team member to do common
integration at that machine. If both team members are remote, this is not possible and
therefore integration needs to be done on the same machine where the development was
done.

 On-site Customer - Video conferencing should be used to involve remote customers. In

DXP, a remote customer is not really an "on-site customer" any more. He/she is more or
less a "virtual on-site customer". The big difference is that the customer needs to conform
to a certain set of rules such as coordination and availability. In order to ensure that we
did not modify XP in general, we would like to revisit the four values of -
Communication, Simplicity, Feedback, and Courage - in the context of DXP.

SSEC I.T. Page 78

 EXTREME PROGRAMMING

 Communication – The use of available tools makes it possible to communicate

effectively regardless of physical location. Therefore, the value of communication in
DXP is as much as it is in XP.

 Simplicity - The philosophy “Make it Simple” doesn’t depend on the physical location of
the team members, so DXP does not affect this value.

 Feedback – The value of Feedback is equally important in DXP as it is in XP. The only
difference is that feedback needs to be propagated across distribution boundaries. If there
are no hurdles in communication among team members, providing effective feedback
should not be an issue in DXP.

 Courage - This value is not affected directly by the distribution of the team. Therefore,
DXP does not modify the four XP values.

DXP can efficiently integrate remote and mobile team members into the development process
and is therefore a valuable extension to traditional XP. In addition, it allows a much more
effective involvement of the customer compared to XP, especially in situations where it seems
impossible to have an on-site customer. DXP can therefore actively broaden the acceptance of
XP as lightweight software development process. We are aware That a virtual meeting through a
computer-supported interaction can never replace direct human interaction. However, there are
situations where such interaction is not feasible, and where a form of XP can still be successfully
employed.

SSEC I.T. Page 79

 EXTREME PROGRAMMING

CONTROVERSIAL ASPECTS
The practices in XP have been heavily debated with strong opinions for or against using
XP.

Proponents of Extreme Programming claim that by having the on-site customer request
changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics
of XP claim this can lead to costly rework and project scope creep beyond what was previously
agreed or funded.

Change control boards are a sign that there are potential conflicts in project objectives
and constraints between multiple users. XP's expedited methodology is somewhat dependent on
programmers being able to assume a unified client viewpoint so the programmer can concentrate
on coding rather than documentation of compromise objectives and constraints. This also applies

SSEC I.T. Page 80

 EXTREME PROGRAMMING

when multiple programming organizations are involved, particularly organizations which

compete for shares of projects

Other potentially controversial aspects of Extreme Programming include:

 Requirements are expressed as automated acceptance tests rather than

specification documents.

 Requirements are defined incrementally, rather than trying to get them all in
advance.

 Software developers are usually required to work in pairs.

 There is no Big Design Up Front. Most of the design activity takes place on the
fly and incrementally, starting with "the simplest thing that could possibly work"
and adding complexity only when it's required by failing tests. Critics compare
this to "debugging a system into appearance" and fear this will result in more re-
design effort than only re-designing when requirements change.

 A customer representative is attached to the project. This role can become a

single-point-of-failure for the project, and some people have found it to be a
source of stress. Also, there is the danger of micro-management by a non-
technical representative trying to dictate the use of technical software features and
architecture.

 Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes,
daisy-chained together. All it takes is for one of them to wriggle loose, and you've
got a very angry, poisonous snake heading your way."

SCALABILITY

SSEC I.T. Page 81

 EXTREME PROGRAMMING

Historically, XP only works on teams of twelve or fewer people. One way to circumvent
this limitation is to break up the project into smaller pieces and the team into smaller groups. It
has been claimed that XP has been used successfully on teams of over a hundred
developers[citation needed]. ThoughtWorks has claimed reasonable success on distributed XP
projects with up to sixty people.

In 2004 Industrial Extreme Programming (IXP) was introduced as an evolution of XP. It

is intended to bring the ability to work in large and distributed teams. It now has 23 practices and
flexible values. As it is a new member of the Agile family, there is not enough data to prove its
usability, however it claims to be an answer to XP's imperfections.

SEVERABILITY AND RESPONSES

In 2003, Matt Stephens and Doug Rosenberg published Extreme Programming

Refactored: The Case Against XP which questioned the value of the XP process and suggested
ways in which it could be improved. This triggered a lengthy debate in articles, internet
newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are
interdependent but that few practical organizations are willing/able to adopt all the practices;
therefore the entire process fails. The book also makes other criticisms and it draws a likeness of
XP's "collective ownership" model to socialism in a negative manner.

Certain aspects of XP have changed since the book Extreme Programming Refactored
(2003) was published; in particular, XP now accommodates modifications to the practices as
long as the required objectives are still met. XP also uses increasingly generic terms for
processes. Some argue that these changes invalidate previous criticisms; others claim that this is
simply watering the process down.

RDP Practice is a technique for tailoring Extreme Programming. This practice was
initially proposed as a long research paper in a workshop organized by Philippe Kruchten and
Steve Adolph( See APSO workshop at ICSE 2008) and yet it is the only proposed and applicable
method for customizing XP. The valuable concepts behind RDP practice, in a short time

SSEC I.T. Page 82

 EXTREME PROGRAMMING

provided the rationale for applicability of it in industries. RDP Practice tries to customize XP by
relying on technique XP Rules.

Other authors have tried to reconcile XP with the older methods in order to form a unified
methodology. Some of these XP sought to replace, such as the waterfall method; example:
Project Lifecycles: Waterfall, Rapid Application Development, and All That. JPMorgan Chase &
Co. tried combining XP with the computer programming methodologies of Capability Maturity
Model Integration (CMMI), and Six Sigma. They found that the three systems reinforced each
other well, leading to better development, and did not mutually contradict.

CRITICISM
Extreme Programming's initial buzz and controversial tenets, such as pair programming
and continuous design, have attracted particular criticisms, such as the ones coming from
McBreen and Boehm and Turner.Many of the criticisms, however, are believed by Agile
practitioners to be misunderstandings of agile development.

In particular, Extreme Programming is reviewed and critiqued by Matt Stephens's and

Doug Rosenberg's Extreme Programming Refactored.

Criticisms include:

 A methodology is only as effective as the people involved, Agile does not solve
this
SSEC I.T. Page 83
 EXTREME PROGRAMMING

 Often used as a means to bleed money from customers through lack of defining a
deliverable

 Lack of structure and necessary documentation

 Only works with senior-level developers

 Incorporates insufficient software design

 Requires meetings at frequent intervals at enormous expense to customers

 Requires too much cultural change to adopt

 Can lead to more difficult contractual negotiations

 Can be very inefficient—if the requirements for one area of code change through
various iterations, the same programming may need to be done several times over.
Whereas if a plan were there to be followed, a single area of code is expected to
be written once.

 Impossible to develop realistic estimates of work effort needed to provide a quote,

because at the beginning of the project no one knows the entire
scope/requirements

 Can increase the risk of scope creep due to the lack of detailed requirements
documentation

 Agile is feature driven; non-functional quality attributes are hard to be placed as

user stories

SSEC I.T. Page 84

 EXTREME PROGRAMMING

XP FAQ’S

I. What is Extreme Programming? Does it involve bungee cords?

Extreme Programming (or XP) is a set of values, principles and practices for rapidly
developing high-quality software that provides the highest value for the customer in the fastest
way possible. XP is extreme in the sense that it takes 12 well-known software development "best
practices" to their logical

II. What does this have to do with Windows XP?

Absolutely nothing. In February 2001, Microsoft announced that the next release of their
consumer Windows operating system would be called "Windows XP". The use of "XP" as
shorthand for Extreme Programming predates Microsoft's use of "XP" by 2-3 years.

III. Is XP a methodology?
No and yes. No, it's not a methodology in the sense of a lot of paperwork and additional
hoops for developers to jump through. But yes, in the sense that it is a repeatable process for
developing software, it is in fact a methodology, although a lightweight one.

SSEC I.T. Page 85

 EXTREME PROGRAMMING

IV. Where did XP come from?

XP was originated by Kent Beck, based on his years of practice as an object-oriented
software developer, and in particular, his work with Ward Cunningham using the Smalltalk
programming language. Because Smalltalk was the first popular object-oriented language, Ward
and Kent have been doing object-oriented programming longer than just about anyone else.

V. What are the basic practices of XP?

The 12 core practices of XP are:

1. Pair programming

2. Planning game

3. Test-driven development

4.Whole team

5.Continuous integration

6. Refactoring or design improvement

7. Small releases

8. Coding standards

9. Collective code ownership

10. Simple design

11. System metaphor

12. Sustainable pace

SSEC I.T. Page 86

 EXTREME PROGRAMMING

VI. What does a typical extreme programming project look like?

The first thing you'd notice is that all the programmers are in a room together, usually
sitting around a large table in the middle of the room. The programmers may have desks or
offices nearby, but you can tell by where the books are piled that the big table is where the action
is.

XP teams work in a series of fixed iteration cycles. Iterations typically last 1, 2 or 3

weeks each depending on the team. (A given team will almost always use same the iteration size
for every iteration.)

At the beginning of each iteration, the team gets together with the customer for a planning
meeting. In that meeting, they go over the features the customer wants done in that iteration,
breaking each feature down into individual engineering tasks. Individual developers then sign up
for specific tasks, and estimate those tasks. No developer is allowed to sign up for more work in
the coming iteration than he completed in the previous iteration.

During the rest of the iteration, the team will implement the features they signed up for,
pair programming on all production code. All code is written test-first -- that is, the developers
don't write any code until they have a failing test case. The developers write unit tests to test
individual classes and subsystems. The customer provides functional or acceptance tests to
validate the features that the programmers are developing.

At the end of the iteration (usually on a Friday), the programmers deliver a working
system to the customer. The system may not be complete, but all functionality that is
implemented works completely, without bugs. The customer accepts delivery, and the team goes
home early. The next Monday everyone meets again to plan the next iteration, and the cycle
repeats itself.

Actual product release is almost a non-event. The customer takes the delivered system
from some iteration, and distributes it to end users. The system is always very nearly defect-free,
so the only question is when the developers have added enough functionality to make it
worthwhile for the end users to upgrade.

VII. How big a project will XP work with?

Easily up to a dozen programmers. Up to twice that with some difficulty. Beyond that,
you'll need something else, either augmenting XP with more traditional heavyweight practices, or
splitting the project among two or more regular XP teams, with some teams becoming the
customers for other teams.

SSEC I.T. Page 87

 EXTREME PROGRAMMING

VIII. How does XP compare to UML?

XP is a development process; UML is a design notation. Most XPers are fluent in UML,
and periodically draw UML diagrams on marker boards to work out design issues. Most XP
projects don't have reams of printed UML diagrams, although there may be a brief design
overview document that contains a few simple diagrams to show canonical class relationships in
the system.

IX. How does XP compare to other lightweight processes, like Scrum, and
FDD?
Scrum is a lightweight process that is philosophically very close XP. SCRUM focuses
more effort removing impediments, with daily stand-up meetings where programmers list any
outside issues that are impeding progress, and a Scrum Master who is tasked with removing those
impediments.

Peter Coad's Feature Driven Development is an iterative lightweight process, but is much
more hierarchical than XP, with a chief programmer, who directs class owners, who direct feature
teams.

For an in-depth comparison of various lightweight processes, see Martin Fowler's paper
The New Methodology.

X. How can you know one approach is simpler than another?

XP actually has a very specific definition of "simplest" (based on the list in Extreme
Programming Explained, p.109):

1. The system (code plus tests) clearly communicates everything that needs to be
communicated at the current instant in its development. This means that it runs every
existing test, and that the source code clearly reveals the intention behind it to anyone
who reads it.

2. The system contains no duplicate code, unless that would violate (1).

3. The system contains the minimum number of classes possible without violating .

SSEC I.T. Page 88

 EXTREME PROGRAMMING

4.The system contains the minimum number of methods possible, consistent with (1) (2)
and (3).

XI. What does "Once and Only Once" (OAOO) mean?

Once and only once is just shorthand for the first two items in the XP definition of
"simplest". (1) says you need to say everything that needs to be said once. (2) says you need to
say it only once, avoiding duplication.

XII. Where can I get a more complete glossary of XP terms?

There's an extensive glossary of XP terms and acronyms available at
http://c2.com/cgi/wiki?XpGlossary. This is part of Ward Cunningham's amazing Wiki system.

Common Objections

XIII. Won't pair programming cut productivity in half?

It turns out that two programmers working as a pair are more than twice as productive as
a single programmer working alone, and also produce higher quality code. The big gain is not, as
you might think, in avoiding little syntax errors, but rather in avoiding the big picture errors -- the
ones where you blow an entire afternoon barking up the wrong tree.

Laurie Williams has done empirical studies of pair programming. Her work is
summarized in the paper The Costs and Benefits of Pair Programming, which she co-wrote with
Alistair Cockburn. In this study, after only a few pairing sessions, pairs of programmers were
roughly as twice as productive as solo programmers, yet produced substantially fewer defects.

XIV. With pair programming and collective code ownership, how are
programmers supposed to be recognized and compensated?
XP has collective code ownership, but individual task ownership. Each developer signs
up for tasks at the beginning of each iteration. He is then responsible for completing those tasks
(by pairing with one or more other developers). At the end of each iteration, the customer decides

SSEC I.T. Page 89

 EXTREME PROGRAMMING

if the task is complete or not. After a year of doing this, the programmer has a long list of
completed tasks to show his manager.

XV. Isn't it annoying having someone looking over your shoulder while you
program?
Pair programming means two people working side-by-side on the same problem on the
same computer; if someone is looking over your shoulder, you're doing it wrong. Typically, the
person "driving" the keyboard and mouse will be focused primarily on tactical issues in coding
the current method, while the non-driver will focus more on strategic issues, like how the method
fits into the system, and is it needed at all in the first places. It's kind of like a road rally, where a
driver and a navigator collaborate to get over a given course in the best time.

XVI. Won't pair programming interfere with "flow", which requires solitude
and silence?
Pair programming appears to access another kind of flow, which is shared between the
two people pairing. There's some talking, but not a lot of idle chitchat, and and it's easier to return
to the state if someone interrupts you.

XVII. Why just pair programming? Why not 3 or 4 or 100 programmers?

There's a communications overhead for each additional programmer you add, and it
grows nonlinearly. With 2 programmers, there's 1 communication path. With 3 programmers
there are 3 paths, with 4, there are 6, and so on. Pairing is just the sweet spot where you get the
benefits of additional minds looking at the problem, but before the communications overhead cost
gets too high.

As a practical matter, when a pair is facing a particularly tough or puzzling task, they
often will call in one or more additional people for help, effectively producing a temporary trio or
even quad programming situation.

SSEC I.T. Page 90

 EXTREME PROGRAMMING

XVIII. Won't simple design leave you with a program that won't scale well?
Simple design, practiced alone typically would have this result. But XP says that after
you do the simplest thing that could possibly work, you go back and refactor your code until
everything your code needs to express appears once and only once within the code base.

CONCLUSION

Extreme Programming is a discipline of software development based on values of simplicity,

communication, feedback, and courage. It works by bringing the whole team together in the
presence of simple practices, with enough feedback to enable the team to see where they are and
to tune the practices to their unique situation.

SSEC I.T. Page 91

 EXTREME PROGRAMMING

REFERENCES

I. Wikipedia. April 2008. Agile Software Development [Online]. Available:

http://www.en.wikipedia.org/wiki/Agile_software_development.com

II. Beck, K. and Andres, C. Extreme Programming Explained. Addison-Wesley,

2004.

III. http://en.wikipedia.org/wiki/Extreme_Programming#Shared_understandig

IV. www.scribd.com

V. www.a2zbooks.com

VI. www.ebookdirectory.com

VII. http://c2.com/cgi/wiki?XpGlossary.

SSEC I.T. Page 92