on 5 February 2015
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.
on 29 May 2014
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.
on 30 March 2012
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.
2 of 3 people found the following review helpful
on 16 April 2010
I'm a software developer looking for ideas of how to implement a small project using XP approach.
This book is not for me or any developer. Kent Beck is introducing the concepts of XP to the audience. In my case, the book is trying to preach the converted. I was looking for advice on HOW to implement the Extreme programming concepts. Instead i got a slight overview of WHAT XP is.
If you know nothing about XP, buy this book.
If you know about XP and want advice on HOW to implement XP. DO NOT buy this book.
1 of 2 people found the following review helpful
on 30 December 2008
This second edition of Kent Beck's seminal book on extreme programming is even better than the first edition. Extensively rewritten, it now draws on the lessons of the last five years to deepen and extend the philosophy behind extreme programming.
I don't know why it is, but it must be significant, that of all the computing books I've read or reviewed in the last two years, the ones about agile and extreme programing stand out for good writing and an ability to project enthusiasm. This book is no exception. One caveat though, don't expect it to give you a checklist to tick off for extreme programming - this is a book concerned with the philosophy of extreme programming.
This book will be of use to a number of different categories of programmers. For those who would like to find out about extreme programming, it is a classy advocacy and explanatory book. For those who would like to introduce extreme programming into their workplace it is chock full of information that can help you win the struggle. Finally for those already practicing extreme programming, this book can fill in the gaps and give you ideas on how to take things forward.
Of, course, there are other things I would have liked to have seen in it. More discussion on large projects for instance, or at the other end, discussion of extreme programming practices for the lone programmer. As the only programmer in my company, I find it difficult to practice pair programming...
But these are not deficiencies - no reasonable sized book can cover everything - and I would heartily recommend this book to any programmer who wants to deepen his or her understanding of the craft. Just one question, Kent. How is it that the prophet of the short cycle and refactoring took five years and a complete re-write to produce the second iteration of his book?
7 of 7 people found the following review helpful
on 14 August 2006
I have to disagree with one of the other reviewers. The first edition of Kent Beck's book was a model of simplicity and clarity. The second edition however seems far less clear, and yet in places is also more dogmatic.
Whereas in the 1st edition there was a simple list of twelve practices, in the second there are 13 primary practices and 11 corollary practices. The lists of principles differ between the two books too, making it hard to understand what some people mean when they talk about XP.
Much of the management discussion has also been removed from the 2nd edition and migrated into a second book.
If you want a clear, unambiguous description of XP, I would strongly recommend trying to find a copy of the first edition.
7 of 8 people found the following review helpful
on 30 March 2006
Most of the negative views here really miss the point and, personally I believe this is down mostly to ignorance or resistance to change. To the reviewer who says "nothing new" - well that is half the point; XP is revolutionary because it is common sense applied to the experience of seeing how things have worked for the last 30 years (also if you studied this book at university I guess you have no or little real world experience of commercial development). Also XP was one of the first of the "new" ideas - it is getting a bit 'old' now but just because most punk sounds like the Ramones that doesn't make the Ramones unoriginal.
To those who say pair programming is impossible you've not tried it your just resistant to an idea that seems wrong as a manager (but you don't have to do pair programming). To those who say "You cannot always be ready to ship, some bits of applications takes weeks until they are just ready for a proper compile" then it is you who needs putting in the humour section as you've missed the point. Unit tests, continuous integration, disciple and good management means you can be ready to ship on a hourly basis (we are in my shop). That doesn't mean it's a completely finished product in terms of features but every feature is finished and works and can deliver business value.
I feel some critism of XP is valid (pair programming isn't right for everyone - but that doesn't mean its wrong) and it doesn't work on large teams (but then large teams may be a 'bad thing') but the truth is most critism sounds like the people who poo-poo'd (and still do) source and change control even though now you are considered a real idiot for not having them - that's the same with unit tests and CI.
6 of 7 people found the following review helpful
on 9 February 2006
Its an easy read, if you can stomach the slightly painful marketing-speak. XP brings silly little things like humanity and respect back into programming.
If you've not pair-programmed or test-driven before then you are missing out on the ideas that Microsoft are still desperately scrabbling to understand. Kent may be walking on the shoulders of giants, but this book has been a watershed for responsible, non-reactive software development.
This, the second edition is even more practical, improving on the original book with a more pragmatic and cooperative business attitude.
There are people out there enjoying their work, helping their businesses to thrive without working all-hours under threat of violence or redundancy. Why not join us?