“Extreme Programming Explained” by Kent Beck, Second Edition (2005)

Introduction

This is a recently-revised edition of the classic, controversial work that put the spotlight firmly on lightweight, iterative software-development methodologies that collectively became known as “agile”.

The first edition of the book was published in 1999. Although iterative methodologies were being used at that time, the waterfall process was predominantly used. Although Royce does in fact describe a partially-iterative approach, most implementations were strictly waterfall in application: the phases of requirements specification, design, construction, integration, testing, installation, and maintenance were each executed, then frozen and signed-off in strict order.

At the same time, software-development toolsets were becoming more powerful. In addition, some programming languages, such as Smalltalk and Java, where becoming flexible enough to model real-world problems and to generate and deploy code from these models. This ability to generate software rapidly, and to elicit feedback quickly from the end-customer, allowed software developers to:

Iterate the waterfall process many times in one project by implementing a software system incrementally;
Be able to deal with requirements that change as a response to business change rather than having them frozen at the beginning of the project.

This approach, along with other features, coalesced into XP.

XP Features

XP has a number of features in common in with other software-development methodologies and a few unique ones.

XP projects are iterative, ie they repeat the same activities in a cyclical fashion, incrementally deploying the system at the end of each iteration, resulting in rapid feedback of any issues. It puts emphasis on intense communication between end-customers and developers.

XP defects

The features that are unique to XP are:

A simple documentation set, especially for requirements and design – the key artefacts are automated tests and code.
Visible artefacts on public display in the work environment, so that newcomers can see the status of the project in a few seconds. This is an idea derived from Lean process of business improvement.
Pair programming, where two developers sit at the same workstation and work on the same code. The idea is to lower the number of defects without having a lengthy, off-line code review.
To aim to develop the simplest thing that could work.

XP Strengths

The projects to which XP is best suited have the following characteristics:

Highly uncertain or rapidly-changing requirements;
Having lower formality – for example less likely to be of a mission-critical nature and less likely to have a high systems-engineering element;
A high degree of human-computer interaction (GUIs), rather than, say, a real-time messaging system;
The stakeholders (especially the developers) have experience of, or are willing to support, highly-collaborative methods of working;
Having a contract that supports iterative working and promotes customer-supplier collaboration.

XP Criticisms

XP has been subjected to a number of criticisms – some more justified than others.

The most common criticism is that it encourages “hacker” indiscipline. This would certainly be justified if XP’s other practices were not followed. However, the practices of pair-programming, the emphasis on testing and limiting the hours of the working week seem far-removed from the work of a lone hacker.

However, another criticism - that pair programming (mandated by XP) is not suited to all developers - has more credence. XP states that those who do not wish pair are shown the door may not be workable (or desirable) in some environments.

Another criticism is that system design is ignored. Certainly, the first edition or the book downplayed its importance. The new edition states more clearly the importance of design but that it should be as lightweight as possible. For this to work efficiently, the team needs to be seeded with a number of experienced XP practitioners.

Another criticism is that XP is silent over how projects interface with other corporate planning activities such as corporate reporting and programme management. This is a valid criticism but links can be made to recognised governance frameworks (PRINCE2) , either directly, or via other practices such DSDM or Scrum.

Summary

So why did this book create such a stir when it first published in 1999? Several other iterative methodologies where in use before this date: Evo (60s); Spiral model (80s); RAD, DSDM, Scrum, RUP, ICONIX (all early- to mid-90s).

Several factors contributed to XP’s notoriety. Firstly, it had a polemical tone; it was a developer-led call-to-arms against a perceived bureaucracy. This was felt to:
• prevent direct contact between developers and end-customers;
• lead to a lack of rapid feedback, leading to frustration in both camps.

Subsequently, some non-XP practitioners became irritated at the publicity XP received. These people re-stated the (sometimes-justified) criticisms - which of course led to more publicity for XP.

XP’s somewhat strident tone has been smoothed in the second edition: a more reflective and holistic view is evidenced. However, the practices seem as radical as ever, for example, the suggestion of making incremental software changes to live system on a daily basis.

Even in its second edition, Extreme Programming Explain remains a powerful and controversial read. Essential for all software and systems engineers – even if only to find out what all the fuss is about.

Additional Thoughts

At Agilier, we have experience using different agile approaches, including XP, in "real-world" situations for our customers' benefit. Please contact us for a no-obligation discussion.