Steve Hayes

Khatovar Technology
http://www.khatovartech.com
[email protected]

An Introduction to Extreme Programming

What is Extreme Programming?

Extreme Programming (XP) is one of a growing group of agile software development methodologies.
XP uses integrated teams of programmers, customers, and managers to develop high-quality software
at high speed. The principal advocate of XP, Kent Beck, brought together a number of tried and tested
software development practices, then leveraged the synergies between these practices to generate vast
improvements in overall productivity and both programmer and customer satisfaction. In particular,
XP builds on the insights of Gerald Weinberg and Tom DeMarco by treating people as the first-order
influence on software development. Working
software is the primary measure of progress. Cost of change

Extreme Programming is viable because of

advances in our understanding of the Traditional
problems we are trying to solve, and because Development
eXtreme Programming
the tools available to us let us change the
previously exponential cost-of-change curve.
XP keeps the cost of change low, so that it's 0
Analysis

Coding

Maintenance
Design
not much more expensive to implement a
feature later than it is to implement it now,
and then leverages this cost-of-change
Traditional Development Phase/Time
environment to produce software faster.

If you're interested in more information on why we need yet another methodology, read Martin
Fowler's article "The New Methodology" at
http://www.martinfowler.com/articles/newMethodology.html.

Why would I use Extreme Programming?

Despite a vast body of research on and experience with development methodologies, most software
projects use an ad-hoc approach to development, characterized by Steve McConnell as "code and fix".
McConnell reports that "several studies have found that 40% to 80% of a typical software project's
budget goes into fixing defects that were created earlier on the same project". Any project in this
situation will benefit from a adopting a development methodology.

To date, most methodologies have treated software development as a manufacturing process, with the
software proceeding along the requirements-analysis-design-code-test-maintain assembly line. This
approach has an important assumption - that the shape of the finished product is known before the
process begins. Most modern software projects can't satisfy this assumption. The customer is
specifying something completely new, and needs constant feedback to validate their choices. In turn,
the programmers need to have a methodology that welcomes changing requirements so that they can
react to the feedback.

If you have an environment where the requirements are expected to change and the customers would
benefit from early and frequent delivery of the software, then you should certainly consider XP. Teams
that adopt XP frequently find they are delivering vastly higher quality software faster than they could
before.

 Khatovar Technology Pty. Ltd., 2001 1

What does an Extreme Programming project look like?

XP is an adaptive methodology, which means that no two XP projects are expected to look exactly the
same. XP documents a set of practices that should be used as a starting point and then adapted to suit
the constraints of your particular project. However, underlying the XP practices are a set of principles
that need to be respected:

1. Communication. An XP team thrives on shared understanding of the problem and the software,
and the most efficient and effective method of achieving shared understanding is face-to-face
communication. Anything that obstructs efficient communication needs to be removed.
2. Simplicity. Simplicity is the art of maximizing the amount of work not done. Dee Hock, former
CEO of Visa International, says "Simple, clear purpose and principles give rise to complex,
intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior".
3. Feedback. Often project teams and their customers don't realize they're in trouble until a short
time before delivery. XP teams get frequent feedback - week to week by delivering working
software, but also minute to minute through testing tools and any other mechanism they can
implement.
4. Courage. Successful software teams need to operate on the edge of chaos - they need to go as fast
as they possibly can without losing control. This means that sometimes they fail. If people are
scared to fail then they'll go too slowly.

XP also promotes twelve practices. If you examine any of these practices in isolation you'll see flaws,
but one of the strengths of XP is that the practices combine in a mutually supporting way, each practice
covering flaws in the others. Each of the XP practices is simple to describe, but requires skill to master.
Together the practices lead to complex, emergent behavior. Each practice has a place in keeping the
cost of change low, and leveraging the low cost of change. The XP practices are:

• Coding Standards • Simple Design

• Testing • Pair Programming
• Collective Code Ownership • Refactoring
• Continuous Integration • Small Releases
• On-site Customer • The Planning Game
• 40-hour week • Metaphor

It's possible to devote a whole book to each practice, so we'll just give a short description of each one
here.

Coding Standards. Coding is a team activity. Over time different people will work on different
pieces of the code, and disparities in coding style and conventions make the code harder to work
with. To be effective we need it to look like all the code on the team was written by the same
person, and we need coding standards to accomplish this.

Simple Design. Keeping the cost of change low means keeping the system as simple as possible.
It also means not spending time and effort implementing features that may or may not be needed
later. XP projects do the simplest thing possible, confident that it can be changed later at little
added cost.

Testing. Every requirement is reflected in an acceptance test. Acceptance tests are owned by the
customer. Programmers write test cases before they write code, using the test to focus on what
they are trying to achieve, and to specify interfaces (test-first-design). All test cases are automated
and run regularly. Programmers can make changes aggressively because the tests will catch
mistakes.

Pair Programming. All production development is done by two people sharing one machine.
Contrary to your intuition, this is much more efficient than having two people program separately.
Pairs rotate frequently, so knowledge and experience ripples through the team. Code is reviewed
continuously.

 Khatovar Technology Pty. Ltd., 2001 2

 Collective Code Ownership. Anyone on the team has the authority to change any of the code,
provided they do it with a partner, comply with coding standards, and ensure that all the tests work
when they've finished. This removes the bottlenecks and architectural distortions that can occur
with individual code ownership.

Refactoring. Refactoring is the technique of improving the design of existing code without
changing functionality. Refactoring is feasible because an XP team has automated tests to catch
mistakes. Refactoring lets us change code to reflect our continually improving understanding of
the problem, and to extend our simple designs over time.

Continuous Integration. XP teams work in small steps, and integrate their code several times a
day. This means that integration problems are discovered soon after they are created, and it's fairly
easy to rectify them. Continuous integration avoids lengthy but incompatible developments, and
helps ensure that everyone is working on the latest version of the system all the time.

Small Releases. Releases should be as small as possible while delivering enough business value to
make them worthwhile (even if the value is just measured in confidence). XP teams can perform
releases in cycles of a few weeks because they are working in small steps, they have tests to catch
regression, and they are integrating continuously. Some XP projects perform a release every day.

On-site Customer. No written requirement is complete and unambiguous. Programmers always

need access to a customer for clarification, no matter how much effort went into the original
specification. An XP team keeps it simple by skipping a lot of the effort put into the specification,
and having a customer available to the programmers all of the time. XP programmers don't guess
the details of a feature, they ask the customer instead.

The Planning Game. XP codifies the regular negotiations over functionality that occur in a
software project and turn them into a game. The Planning Game is run every iteration (every few
weeks) to determine what functionality will go into the next (small) release. Programmers make
technical decisions (estimates) and customers make business decisions (selecting the functionality
with the most benefit), and everyone does it with full knowledge of the current, working system.

40-hour Week. Software development is a creative exercise, and no one can be creative if they're
exhausted. Restricting the number of hours in a work week keeps people fresh, reduce staff
turnover, and improves the quality of the finished product. Other XP practices help the team to
deliver a competitive quantity of software (however you measure it) in a regular week.

Metaphor. The system metaphor gives the team a consistent vocabulary for discussing their
problems and their solutions. It could be "this system is like an assembly line", or it could mean
talking about the system in terms of business objects.

Who else is using Extreme Programming?

There are informal estimates that at least 100 projects in the USA are using XP, and the number is
growing continually. XP is also becoming very popular in Europe. You can see a list of companies
actively recruiting XP-qualified staff at http://www.extremeprogramming.org/people.html.

Extreme Programming is less common in Australia. Thoughtworks (Melbourne) is participating in a

global project that uses XP. There have also been a few XP projects in Macquarie Bank (Sydney).
Many more people are using subsets of the XP practices to improve their productivity and reduce risk.

Khatovar Technology (http://www.khatovartech.com) is providing support for XP practices within

Australia.

 Khatovar Technology Pty. Ltd., 2001 3

How do I learn more about Extreme Programming?
There are lots of resources on the web, and a growing number of books. For more introductory
material, start with "Extreme Programming Explained: Embrace Change" by Kent Beck, and visit
"Extreme Programming: A gentle introduction" at http://www.extremeprogramming.org.

Khatovar Technology provides a list of XP related resources, including books, web sites, mailing
groups and news items at http://www.khatovartech.com/resources/index.html.

In Melbourne there is an Extreme Programming Enthusiast's Group (MXPEG). News and meetings are
announced via http://groups.yahoo.com/group/melbourne_XP_enthusiasts.

Bibliography
• Beck, K., "Extreme Programming Explained: Embrace Change", Addison Wesley Longman, 1999
• Collins, C., and Miller, R., "XP Distilled",
http://www.rolemodelsoft.com/articles/xpCorner/xpDistilled.pdf
• Highsmith, J., "Adaptive Software Development: A collaborative approach to managing complex
systems", Dorset House, 2000
• McConnell, S., "After the Gold Rush: Creating a True Profession of Software Engineering",
Microsoft Press, 1999
• Weinberg, J., "The Psychology of Computer Programming", Silver Edition, Dorset House, 1998

 Khatovar Technology Pty. Ltd., 2001 4