Extreme Programming Explained: Embrace Change Paperback – Illustrated, 16 Nov. 2004

If you already know XP, you perhaps want to know whether to buy this book. I'll try to answer that question.The first edition of this book marked a watershed in the way I thought about software. I did leave many questions unanswered, however, as our team struggled to implement the practices 'out of the box'. Perhaps a bit too much revolutionary zeal.The breadth of the second edition is far greater. It explains the principles so that you can adapt them to your own circumstances, without subverting their original intent. As such it is a far more usefull book than the first edition, even if it lacks the bold audacity of the former - or maybe the ideas of XP dont seem so left of field anymore.

I've been part of an agile transformation for 18 months, and have been embracing a lot of the concepts in the book due to some great coaching. However I've recently left said company, so it has been great to read about embracing change, reaffirming my views and learning new perspectives, which I can now introduce to my new company, who are at the start of their agile transformation.

This is a 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 has a number of features in common in with other software-development methodologies and a few unique ones. The common features are that 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.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.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 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. The statement 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 system design. 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 such as (PRINCE2), either directly, or via other practices such as DSDM or Scrum.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. 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 and lead to a lack of rapid feedback, leading to frustration in both camps. In addition, 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.The 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.

It was only after reading this book that I realized there might be value in this "agile" thing. There's more to agile than Scrum-branded processes and tools, and XP is much more than just "agile technical practices". The XP practices are good, but it's really the values and principles that matter.

I have put off reading about XP for a while because I thought that it wasn’t required to be a good developer. I stand corrected now and would recommend this book to be a requirement for all developers.

Very pleased with this a must read for any agile team. If you run a team make everyone read this book it is so worth it.

Very well written, a must-read for software developers and people in the software development business.Would recommend it to anyone.

Bertrand Meyer's damning critique of XP in "Agile! The Good, the Hype and the Ugly" is, if anything, too generous. Not only does Beck not have anything valuable to contribute to the engineering of quality software, this book, despite its title, has nothing to do with programming and does not explain anything.