Now this is a controversial book that has caused a lot of heated debate among developers. It starts out innocently enough, by stating the goals of XP which most everyone will agree on: correct, flexible software that adapts well to change in requirements and user-feedback, short development times and happy programmers and customers. It then goes on to explain how the techniques of XP try to help archive these goals. The practices include widely accepted ones, like a rigorous testing process, coding standards and continuous integration. But it also breaks quite radically with common programming wisdom by requiring things like an on-site customer, refactoring as a major component instead of a complete up-front design, pair programming (two developers sharing one keyboard and one screen) and collective code ownership (every one on the team is responsible for the whole codebase and allowed to modify every line of it). It is this mix of proven techniques taken to the extreme and new approaches presented in the book that Beck claims creates a special synergy which leads to a more successful and less strenuous software development process. The author puts forward very convincing arguments for why and how these synergetic effects occur and presents his personal experience using XP on one team as supporting anecdotal evidence. The book is written in an easily readable style and contains lots of sometimes funny anecdotes and quotes. And although it obviously is about the author's pet idea I didn't find it preaching, but rather refreshingly enthusiastic and energetic.
Unfortunately I have to admit that I haven't yet personally experienced all XP techniques in practice, main reasons being that it's very hard to convince management of it's merits ("What?! Two programmers on one keyboard?! No way!") and to get all team members willing to try something new. Maybe if they'd all read this book it would be easier...
In the unlikely event that the ideas don't intrigue you, you still have to buy this book to know what all the hype and controversy is about.

When I read the first edition several years ago, my first thought was how XP needs a name change. It seems as if Beck said, "Lets take a bunch of common 'best practices', develop a methodology around performing them consistently, and then give it a name that will scare away managers".

XP is not a silver bullet, not is it 'evil'. If you develop software and you work in an environment where you always seem to struggle with issues that prevent your team from operating effectively, then this book is for you. Extreme Programming is about taking several core 'practices' and 'values', and turning that into a methodology - perhaps even a philosophy - of software development, team interaction, and process improvement. I don't care if you end up falling in love with XP or if you end up following RUP, CMMi or some other improvement framework, reading this book is an excellent first start to pull yourself out of the doldrums that most software development shops operate in.

Yes, I am a fan of XP and this book. I think the first edition was better. This book seems to digress a lot into touchy-feely subjects, rather than staying on the subject of software development (for example, there are a few pages about personal relationships in the workplace, including dealing with issues that cross the line into HR management - not appropriate for a book that is supposed to be about XP). Beck also seems to flip-flop between describing XP as a solid methodology and a loose collection of his own ideas. I think that XP would greatly improve if it grew up and formalized itself a little better... XP should not be defined with the primary author's telling of anecdotal stories, as appear in this book.

Read it with a pragmatic eye, and figure out what is relevant to your situation. Trying to apply these (or any) ideas dogmatically will probably solve some issues while creating far worse ones.

Whether or not interested in Extreme Programming, a software developer should certainly read this book. As a warning, the book is not a detailed techinal guide of how to apply XP. It's more of a emotional guide of how to better ourselves as being a programmer. This book reminded me that, I am a human who have values and ideals, not just a machine, writing code only to make some money. If you have huge amount of technical knowledge and experience and still feeling something is wrong, this is the book which will enlighten your path.

Maybe I'm too cynical because I never got to work for the successful, whiz-kid companies; Maybe this book wasn't written for me!

This book reminds me of Jacobsen's "Use Cases" book of the 1990s. 'Use Cases' was all the rage but after several years, we slowly learned the truth: Uses Cases does not deal with the architecture - a necessary and good foundation for any piece of software.
Similarly, this book seems to be spotlighting Testing and taking it to extremes.

'the test plan is the design doc'
Not True. The design doc encapsulates wisdom and insight
a picture that accurately describes the interactions of the lower level software components is worth a thousand lines of code-reading.

Also present is an evangelistic fervor that reminds me of the rah-rah eighties' bestseller, "In Search Of Excellence" by Peters and Waterman. (Many people have since noted that most of the spotlighted companies of that book are bankrupt twenty five years later).

- in a room full of people with a bully supervisor (as I experienced in my last job at a major telco) innovation or good work is largely absent.

- deploy daily - are you kidding?
to run through the hundreds of test cases in a large application takes several hours if not days. Not all testing can be automated.

- I have found the principle of "baby steps", one of the principles in the book, most useful in my career - it is the basis for prototyping iteratively. However I heard it described in 1997 at a pep talk at MCI that the VP of our department gave to us. So I dont know who stole it from whom!

Lastly, I noted that the term 'XP' was used throughout the book, and the back cover has a blurb from an M$ architect. Was it simply coincidence that Windows shares the same name for its XP release? I wondered if M$ had sponsored part of the book as good advertising for Windows XP! :)

In Kent Beck's first edition he articulated a manifesto for lightweight methodologies. These methods today are referred to as Agile Methodologies; which Extreme Programming is only one.

The Second Edition builds on the first edition but has a distinctly different tone. In the first book XP was a described as 12 practices that may or may not have been new but the aggregation of the 12 brought together something that as whole changed the way many people wrote software. In this book more emphasis is placed on the whys behind the practices which include values and principals. For example, here is a quote from the book, "Values bring purpose to practices". Kent goes on to say that if he told you to follow practices blindly some people would but most people want to know why you might do a practice. Here is where the values and principals come in to give you the reasoning why a practice is useful. Overall given the renewed emphasis on values, principals, and practices I thought the book itself was much more approachable than the first edition which hopefully will encourage the people who had been on the fence to try out the practices on their next project.

Even if you don't plan on adopting XP, this is worth a read. It's concise, reads quickly and has a nice table of contents.

The chapter on the four variables in projects was one of my favorites. It will give you a clue what to say next time everything needs to be done yesterday. The chapter on test first development was also useful and I've had great success with its techniques.

This book is worth a read even if you're initially turned off by XP. Even though it's on a specific development strategy, much of the information is useful everywhere.

I have been using Agile programming methods for some time, so I decided to find a book to describe the details of Extreme programming. Extreme programming is an important variant of Agile programming so it is worth studying in more detail.

I bought this book with the expectation that it would be a serious description of how to apply extreme programming and how it relates to other methods. No such luck. The book does explain practices and philosophies, but is primarily an emotional pep talk in favor of Extreme programming. This is to much "Zen" for me. And it seems that the pep talks mostly compared it to the trational waterfall model. In this comparison it is no wonder that extreme programming seems so good. But the book gives seriouos indication of why this method is best; as it claims it is.

So overall, it is an adequate book that does fairly good job presenting what extreme programming is all about but it could have been so much better.

Whatever you do, don't read this book as your first book on software engineering. For that purpose I recommend Steve McConell: Rapid Development. Reading books on agile development should happen after that - otherwise it might be hard to see things in the right perspective.

If the first edition of this book was a warning shot across the bow of heavyweight methodologies, then this new edition is a call to arms for any team that wants to develop better software faster, and have fun doing it. XP is now being used by teams and in contexts unthinkable when the first edition of this book was published.

This edition is a completely new version of the book. For example, there are new chapters on Taylorism, lean manufacturing, and the theory of constraints. There are many new ideas and XP is now explained more in terms of its values and principles than through strict adherence to twelve specific practices.

In this new edition, Kent Beck expands on the vision of the first and shows us how XP--through the application of its values, principles and practices-has become more than just a lightweight method for small to medium teams. XP represents an evolving way of thinking about software development. I can think of no better person than Kent Beck to show the way.

In his second edition Kent has defined Extreme Programming as a journey and not a destination. This new edition is a realization that all projects start out with some good and some bad mixed together. This new edition also has more for people in enterprise situations.

Kent underscores his belief that a team's values are the most important criteria of a project. Extreme Programming is no longer a restrictive set of practices to be measured against. Kent encourages people to start with the set of practices he has seen work but then go even further by using the principles to create new practices for unique situations.

In the end what Kent has written down is more uniform practices, greater stress on the values, and a set of principles that are equal in importance to the practices. These are things I notice eluding people who read the first edition.

The release 1st edition of this book is still considered by many to be the kick start for the growing adoption of a software development process called Extreme Programming. After 5 years, the 2nd edition faces a much different world but also with much different content and approach. The world has learned much and so has the author. I'm glad to see that this 2nd edition reflects that development.

Beck has revised his thinking throughout the book. Some obvious examples include his current preference towards using ideal time over abstract time units in estimating, the fifth value among the initial four, the new set of principles, and the rehash of the practices.

Extreme Programming Explained is not a detailed how-to for adopting the process it describes. Actually, it doesn't really describe a process at all. What it does describe is a system of values and principles and a set of practices to support these. Even though Beck does give each practice (divided into primary and corollary practices in the 2nd edition) their share of explanation, the focus is still strongly on the "what" and "why" instead of the "how".

As someone who has read a dozen books on the topic already, I was delighted to find almost every page to provide something intriguing that either created or challenged my own thoughts. Especially the latter half of the book, dealing with topics such as TOC, scaling, Taylorism, the Toyota Production System, and the hot potato itself -- offshoring -- offered a lot to think about.

This is what a 2nd edition should be like, every single chapter reflecting new insight gathered over the years.

This book updates basic concepts that don't need to be reserved for programmers. Working on a lot of ERP/APS projects, I appreciated reading an approach that accepts that change happens, no matter how much upfront planning you do. The traditional approach has a lot of overhead -- management, documents, design -- and makes responding to needs difficult and in many ways actually detracts from the value of the ultimate deliverable, a functioning system.

I worked on a project (before reading this book) that reflected some of the tenets: don't build for the future but for current requirements, have testing going on all the time (automated and manual), work with others as much as possible, don't be afraid to try something different, etc. The project culture was very supportive. As a note, our programmers were all offsite, but very responsive -- since they worked together we could always reach someone who could address our issues. I think there is some leeway for the onsite customer requirement given the sophistication of technology today.

The main drawback to XP is that it relies on the strengths and compatibilities of people. If the environment in which you are trying to introduce this approach does not have a positive culture and talanted people (learning is allowed!), you've got issues that will negitively affect any undertaking -- it may simply be covered up better in all the clutter.

This is a complete re-write.

The only thing that is the same is the title (with the appended Second Edition). The old foreword is included as well though Erich Gamma wrote a new one. Amazon seems to be re-using the back cover words from the first edition which is misleading because even that is different. I would also suspect that are many reviews here by people who haven't read this second edition, thinking it's just a revision.

I must admit that I liked the bravado of the first edition, and even more so the first inklings of XP on the Portland Pattern Repository. However, I like the authenticity of this second edition more. There is a much greater sense of "Whole Team" while in comparison, the first version is an expression by programmers.

Probably the key thing is that this was written with the context of a lot of people who have tried XP or at least tried to go in that direction, in the five years since the first edition was published.

Much clearer communication of the relationships between values (universal), principles (domain-specific), and practices (concrete). Values and principles are "Why" and practices are "How". I would suggest that much of the resistance to XP comes from a disagreement over values and principles, though it manifests as a disagreement over practices. XP is a change in culture, in relationships, not just a change in technique. This is why it is so appealing to some, and so frightening to others.

It's interesting to see how much of what the community has learned is incorporated into this edition. There's mention of Theory of Constraints, Toyota Production System, etc.

"I hope that in reading and applying this book you will come to a deeper understanding of why you are involved in software development and how you can find satisfaction from this work."

I can honestly say that this book helps restore my hope that we can make a difference for the better.

The first edition of this book provoked me to get on an XP team and see if it really works. It does. In the ensuing years, I've worked on 3 teams which used XP values, principles and practices and achieved great success, and 1 team which did not and achieved some success at great human cost (the best members of the team burned out and left).

The new edition inspires me anew. My favorite new chapter is the principles. These reflect what the teams I've been on have learned through trial and error. What a bonus to start off knowing and applying these principles!

There are a lot of misconceptions about XP (see other reviews here - a common one is that there's no documentation). All I can say is, read this book, really understand and apply the values, principles and practices to a project. It's not any easier than applying any traditional methodology. The difference is that it really works. And the reason is that it's all about people and helping a team do its best work.

This book is undoubtedly a classic. One of the neatly ordered book I have read in a while. It presents to a novice planner on becoming more productive. However, if you are a novice who has just stepped into the world of programming...then maybe this is not the right time for you to read this book. Maybe after 2 years, once you are comfortable in makind informed sensible decisions, this book becomes a MUST READ.
Any manager, senior developer or anybody who leads a bunch of programmers...yes...a MUST READ.

As much as this book advises on what to do and what not to do for XP....towards the end, it gets a bit too cautious. The author tends to playing it safe by telling that XP is not for everyone. Though, I admit to the fact that he is not trying to say anywhere that XP is THE WAY...but he does not reinforce that XP is a nice way very often.
The book contains many words of wisdom...and as you read through it gives you the opportunity to review yourself as a programmer. The book describes programmer attitudes and smart people working in a team following XP. While the author tells what a good programmer practicing XP should do, he also points out to the plain facts...as to what programmers in the initial stages of XP do...
Though not directly related to code, the author describes a few practices while developing code, that can be followed even when one is not coding "XP-STYLE"

This book is certainly a classic....but as a word of caution...do not read the whole book if you have just begun to program. The wait is really worth the philosophy the book preaches.

Maybe it's an interesting idea, but it's just not ready for prime time.

Parts of Kent's recommended practice - including aggressive testing and short integration cycle - make a lot of sense. I've shared the same beliefs for years, but it was good to see them clarified and codified. I really have changed some of my practice after reading this and books like this.

I have two broad kinds of problem with this dogma, though. First is the near-abolition of documentation. I can't defend 2000 page specs for typical kinds of development. On the other hand, declaring that the test suite is the spec doesn't do it for me either. The test suite is code, written for machine interpretation. Much too often, it is not written for human interpretation. Based on the way I see most code written, it would be a nightmare to reverse engineer the human meaning out of any non-trivial test code. Some systematic way of ensuring human intelligibility in the code, traceable to specific "stories" (because "requirements" are part of the bad old way), would give me a lot more confidence in the approach.

The second is the dictatorial social engineering that eXtremity mandates. I've actually tried the pair programming - what a disaster. The less said the better, except that my experience did not actually destroy any professional relationships. I've also worked with people who felt that their slightest whim was adequate reason to interfere with my work. That's what Beck institutionalizes by saying that any request made of me by anyone on the team must be granted. It puts me completely at the mercy of anyone walking by. The requisite bullpen physical environment doesn't work for me either. I find that the visual and auditory distraction make intense concentration impossible.

I find revival tent spirit of the eXtremists very off-putting. If something works, it works for reasons, not as a matter of faith. I find much too much eXhortation to believe, to go ahead and leap in, so that I will eXperience the wonderfulness for myself. Isn't that what the evangelist on the subway platform keeps saying? Beck does acknowledge unbelievers like me, but requires their exile in order to maintain the group-think of the X-cult.

Beck's last chapters note a number of exceptions and special cases where eXtremism may not work - actually, most of the projects I've ever encountered.

There certainly is good in the eXtreme practice. I look to future authors to tease that good out from the positively destructive threads that I see interwoven.

Mr. Beck has managed to write a book based upon his own opinions and theories, not of which are based upon facts or solid research, and sell this idea as a development methodology/paradigm shift. More power to him for his own marketing ability. I do have some respect for him as a developer after reading Refactoring with Martin Fowler as the primary author.

My Ph.D. work was done on how technology affects the coomunication and learning process. And I have 14 years of experience watching students work in teams on programming problems. What Mr. Beck writes about the paired-programming aspect is contrary to common sense and anyone even the slightest inkling of perception into the personality traits of developers.

He does make some good points about manamgement, and time estimates. Unfortunately the good things are mixed in with the fantasy. I've yet to encounter a software/technology manager and very few developers that have the people skills; or any education or innate ability of learning and teaching styles that would be absolutely necessary for his suggestion to be sucessful.

It was my unfortunate (depending on your viewpoint) experience to work with a development team at Intel trying to implement Extreme Programming for the first time. That experience is worth a whole book in itself.

I suggest reading the book, take the good stuff, but please don't confuse opinion or limited personal experience as suitable justification for imposing bizzare practices on your development teams.

The book presents extreme programming. It is divided into three parts:
(1) The problem
(2) The solution
(3) Implementing XP.

The problem, as presented by the author, is that requirements change but current methodologies are not agile enough to cope with this. This results in customer being unhappy. The solution is to embrace change and to allow the requirements to be changed. This is done by choosing the simplest solution, releasing frequently, refactoring with the security of unit tests.

The basic assumption which underscores the approach is that the cost of change is not exponential but reaches a flat asymptote. If this is not the case, allowing change late in the project would be disastrous. The author does not provide data to back his point of view. On the other hand there is a lot of data against a constant cost of change (see for example discussion of cost in Code Complete). The lack of reasonable argumentation is an irremediable flaw in the book. Without some supportive data it is impossible to believe the basic assumption, nor the rest of the book. This is all the more important since the only project that the author refers to was cancelled before full completion.

Many other parts of the book are unconvincing. The author presents several XP practices. Some of them are very useful. For example unit tests are a good practice. They are however better treated elsewhere (e.g., Code Complete chapter on unit test). On the other hand some practices seem overkill. Pair programming is one of them. I have tried it and found it useful to generate ideas while prototyping. For writing production code, I find that a quiet environment is by far the best (see Peopleware for supportive data). Again the author does not provide any data to support his point.

This book suggests an approach aiming at changing software engineering practices. However the lack of supportive data makes it a work of fiction.

I would suggest reading Code Complete for code level advice or Rapid Development for management level advice.

"Extreme" programming (XP) is a relatively new software development methodology which aims to allow small teams to produce higher quality software in less time, with less stress. The only thing that possibly exceeds the fervor of its adherents is the scorn heaped upon it by skeptics. _Extreme Programming Explained: Embrace Change_ is "the XP manifesto", which lays out the basic tenets of the XP idea, discusses the philosophy behind the principles, and delves into actually implementing XP in a programming team. I found the book to be a quick read, and I'm sure if you're about to start working with an XP team (in either a developer or a customer role), it would be a good place to start familiarizing yourself with the theory and practice of Extreme Programming.

The first third of the book lays out the principles and the theory behind Extreme Programming, and reflects on how the realities of current software development don't match up with classic development methodology that well anymore (if they ever did). By the end of this section, if you've been involved with any sort of structured software development, you'll be nodding your head in agreement and/or cringing from the painful memories of past failed projects.

The middle third of the book starts out with a high-level overview of the mechanics of the XP process, and then quickly gets into the nitty-gritty of carrying out the distinct steps: The Planning Game, small releases, pair programming, collective ownership, refactoring, testing, and all the rest. Even if you don't go for full-bore XP practices, there should be something in this section that will make you re-think some of your practices.

The final third of the book deals with practical considerations of implementing the XP methodology for software development, including when you shouldn't try to use XP. This section, with recountings of commonly encountered problems, and descriptions of the different roles often filled by XP programmers, will be the most valuable for someone trying to actually turn theory into practice.

Overall, I found the book to be a quick, interesting read, and it was fun to consider how some things at my workplace would happen differently if some XP practices were to be adopted.

Kent Beck has pulled together many simple software development values and principles into a profound and cohesive book (and methodology). It is so simple yet I do see this as a real challenge for some IT departments to accept and utilize...but it's how software should be developed any more...or at least this should be the initial approach (keep it simple). He explains so well how, why and when it can and can't work.

I really enjoyed the short and consice chapters. It's extremely easy to follow.

But unfortunately it is..and badly! It is a
very clear, effective introduction to the development
style and discipline that 's trying to give control of software development back to programmers and away from dumb managers,
fluff vendors and the like. It does so through the application of a minimum of common sense and encouraging the creation of simple, effective software over the production of heavy, useless documentation. A useful conversation with a "good programmer with great habits".

If you are considering Extreme Programming, you should read this text.

The book is divided into 3 sections -- 1) The problem , 2) the solution, and 3) the implementation. The problem covers the 4 basic values of Extreme programming
1. Communication
2. Simplicity
3. Feedback
4. Courage

And it also covers the basic practices that support these values -- namely incremental delivery, unit testing, collective ownership, and paired programming.

The solution goes into more detail on the strategies behind the practices. Section 3 imnplementing XP covers roles for people, and strategies to make an XP implementation successful.

If you are familiar with other agile approaches like Scrum, most of the material will be familiar to you. Unlike some other agile approaches, this is a full lifecycle approach and the author covers project management, design, programming, and testing.
Extreme programming advocates decentralized decision making, but there is a good section on the role of the manager or coach.

Some of the practices depart from conventional SW Development wisdom. For example, there is a good explanation of how the cost of a change may not rise drastically over time.

The text covers metric collection and discusses velocity -- ratio between estimated development time and calendar time. However, I wish there was more time spent on ways to communicate these metrics to the team and management.

Overall, great introductory to Extreme Programming and a good reference.

This book does an excellent job of painting an accurate portrait of a methodology that has been hyped as the salvation for all programming ills. It's clear that XP is just another methodology and is limited to very specific types of programming environments and corporate cultures.

Beck's book is an outstanding summary of a great development practice. I picked up his book for no real reason, but was so compelled by the arguments, that our little software development group implemented (most of) his suggested practices. Naysayers can say what you would like - 5 appplications and 5 contracts later, our company is growing, the customers are happy, the applications are in widespread and increasing use. This book describes a revolution built upon common sense.

Kent presents controversial concepts into software design with some very interesting ideas that I wish I could observe to see if in practice XP would work. When I am reading the text I am thinking this is very idealistic and not realistic. It is not to say that a good group of people could chose to use such a system, however it is my opinion their are specific number of individuals in a development team who tend to be intellectual snobs, selfish knowledge hogs, selfish code hogs, ruler dominators of the project, or those whose knowledge is outdated that they resist change for the sake of job security. If XP were enforced these type of people would be blown away in the design team environment. XP is a collective effort where talents of the individual work for the greater good of the project, not for glory of the individual so that they look good and get raises or promotions or derive power. A concept foreign to most intellectual snobs who see the whole design but refuse to share information in order maintain control and power over the project. Therefore, for XP to work, one has put the project above his or her own ego.

XP also demands the obliteration of office politics and the institutions that harbor power. Kent describes managers as guides not as enforcers, because no one likes to be told what to do. Being told what to do is counter productive. I agree! XP diffuses and replaces power with functionality and the byproduct is productivity. However again for this to work ego has to go and the project is place above the individual.

I can see why those who love institutions, structure, those who love power, office politics, bureaucracy and build their careers on concrete absolutes would hate and denounce Extreme Programming. Extreme Programming short circuits the long time tested built pillars of "so-called best practices". Why would these PHD's, experts and long time die hards put their careers at stake? It would be like a hard core evolutionist, embracing creationism in forum of instituionalized evolutionists. The answer is because change means that they are no longer viable, if they do not change. Change will wreck everything! So, its better to stay in the horse and buggy age as long as it puts money in my pockets and puts food on my table. If there is ever a threat to interupt the institution which I support then all that oppose my security must be denounced.

I agree with Kent Beck, let's "EMBRACE CHANGE"

I'm about halfway through this book and it is a joy to read. It is so beautiful in its wisdom and simplicity. Extreme programming seems to make a lot of sense as long as your mates are

a) Marginal competent,
b) Don't think of pair programming as a struggle for dominance,
c) Can accept criticism without throwing a fit that would embarrass a toddler.

Regrettably, none of these traits can be attributed to the pair I currently work with, so this book has inspired me to look for a new job. But I know I won't find myself in the same position since this book has showed me the red flags to look for while interviewing.

It's interesting to see the phenomenon of Extreme Programming happening in the dawn of the 21st century. I suppose historians can explain such a reaction as a truly conservative movement. Of course, serious software engineering practice is hard. Heck, documentation is a pain in the neck. And what programmer wouldn't love to have divine inspiration just before starting to write the latest web application and so enlightened by the Almighty, write the whole thing in one go, as if by magic? No design, no documentation, you and me as a pair, and the customer too. Sounds like a hacker's dream with "Imagine" as the soundtrack (sorry, John).

The Software Engineering struggle is over 50 years old and it's only logical to expect some resistance, from time to time. In the XP case, the resistance comes in one of its worst forms: evangelism. A fundamentalist cult, with very little substance, no proof of any kind, but then again if you don't have faith you won't be granted the gift of the mystic revelation. It's Gnosticism for Geeks.

Take it with a pinch of salt.. well, maybe a sack of salt. If you can see through the B.S. that sells millions of dollars in books, consultancy fees, lectures, etc, you will recognise some common-sense ideas that are better explained, explored and detailed elsewhere.

#1
Perhaps the most illustrative anecdote is on page 78, where the author includes a picture of what pair programming looked like in "The DaimlerChrysler C3 work area". They trusted their payroll system to XP.
It's an unfortunate choice of words: "Extreme".
I'd use the phrase "Team programming" if you work for a corporation - that seems to fit right in.
#2
How would you feel if there were a button on your application labelled "test", and when you clicked on it, it ran a battery of tests that all returned 100% correct? Would that boost your confidence maybe? That's one of the concepts behind TDD (Test Driven Development). I call them diagnostics, because testing can be confused with "testing something before it goes into production".
This is for after it's gone into production.
"Is the system working?" asks the boss.
"I don't know, let me see" you say. You press the "test" button, and it returns a yes.
"Yes it is".
Similarly, any new development that you do must be accompanied with a test of its own.

The concept of extreme programming (XP) is new and interesting, though its probably not used in a lot of large software organizations, who tend to be bent on SDLC (for reasons that would become obvious when you read the text). It talks about design principles when building software that isn't considered critical (e.g. real-time applications) and when programmer count is less than 10. Has interesting principles on peer programming, testing, requirements gathering and refactoring. It kinda takes the approach of do what you have to do now, and worry about adding more functionality later, if necessary. Some of its philosophies can be adopted into the design principles you're currently using, but the author states that if you dont follow it all, then your not fully practicing XP.

A good read, adds to your insight of the design processes out there. Its good to have an idea of different design processes so you can pick one that suitably applies to what you're currently working on. I applied it in a team of about 10 programmers on a school project, and when programming with a partner on a project, using XP was actually fun.

This is a short simple explanation of the new discipline of 'Extreme Programming'. Fast to read, easy to understand. So much for the book. I have doubts about Extreme Programming, it seems either unworkable or something we already do anyhow (contradictory statement, i realize!).

To fairly review this book, one must distinguish between the methodology it presents and the actual presentation. As to the presentation, the author attempts to win the reader over with emotional persuasion and pep talk rather than with facts and hard evidence. Stories of childhood and comradeship don't classify as convincing facts to me. A single case study-the C3 project-is often referred to, but with no specific information (do note that the project was cancelled by the client after staying in development for far too long).

As to the method itself, it basically boils down to four core practices:
1. Always have a customer available on site.
2. Unit test before you code.
3. Program in pairs.
4. Forfeit detailed design in favor of incremental, daily releases and refactoring.

If you do the above, and you have excellent staff on your hands, then the book promises that you'll reap the benefits of faster development, less overtime, and happier customers. Of course, the book fails to point out that if your staff is all highly qualified people, then the project is likely to succeed no matter what methodology you use. I'm sure that anyone who has worked in the software industry for sometime has noticed the sad state that most computer professionals are in nowadays.

However, assuming that you have all the topnotch developers that you desire, the outlined methodology is almost impossible to apply in real world scenarios. Having a customer always available on site would mean that the customer in question is probably a small, expendable fish in his organization and is unlikely to have any useful knowledge of its business practices. Unit testing code before it is written means that one would have to have a mental picture of what one is going to write before writing it, which is difficult without upfront design. And maintaining such tests as the code changes would be a nightmare. Programming in pairs all the time would assume that your topnotch developers are also sociable creatures, which is rarely the case, and even if they were, no one would be able to justify the practice in terms of productivity. I won't discuss why I think that abandoning upfront design is a bad practice; the whole idea is too ridiculous to debate.

Both book and methodology will attract fledgling developers with its promise of hacking as an acceptable software practice and a development universe revolving around the programmer. It's a cult, not a methodology, were the followers shall find salvation and 40-hour working weeks. Experience is a great teacher, but only a fool would learn from it alone. Listen to what the opponents have to say before embracing change, and don't forget to take the proverbial grain of salt.

Two stars out of five for the presentation for being courageous and attempting to defy the standard practices of the industry. Two stars for the methodology itself, because it underlines several common sense practices that are very useful once practiced without the extremity.

This book is simplistic. It glosses over the complete psychology involved in developing code with a team. I was very disappointed comparing what this book preaches and what it uses to substantiate its percepts. The analogical nature of the book doesn't allow one to anticipate problems and resolve them. As a programmer I don't think the book describes things as they are in team interactions. I'll keep my copy of the book. Some of the things written in it are so ludicrous as to be funny.

Caveat: I have never worked in an XP shop, that is, a software shop that puts into place all the principles of XP. However, many shops I've worked in have put one or more principles described in Kent Beck's book into effect, and in those cases, those processes made a remarkable difference in the ability to deliver products on time and under budget. This thin book is a great place to get some great common sense -- e.g., that it's futile to assume that if you just spend enough time in "design phase" that the software project will go better. Very practically, every successful project I've worked on has had architects that coded, has had continuous integration and testing, lots of developer communication and cooperation, and strove always to maintain short development cycles with lots of customer feedback.

Beck's book is direct, straightforward and undogmatic. It's also lighweight and concise itself, a considerable virtue in this field. I recommend it.

Any Engineering discipline is based on solid reasoning and logic not on blind faith. Unfortunately, most of this book attempts to convince you that Extreme programming is better based on the author's experiences. A lot of the principles are counter - intutive and the author exhorts you just try it out and get enlightened. I'm sorry but these kind of things belong in infomercials not in s/w engineering.
The part about "code is the documentation" is the scariest part. It's true that keeping the documentation up to date is tough on any software project, but to do away with dcoumentation is the most ridiculous thing I have heard. It's like telling people to cut of their noses to avoid colds.
Yes we are always in search of a better software process. Let me tell you that this book won't lead you there.

Now this is a controversial book that has caused a lot of heated debate among developers. It starts out innocently enough, by stating the goals of XP which most everyone will agree on: correct, flexible software that adapts well to change in requirements and user-feedback, short development times and happy programmers and customers. It then goes on to explain how the techniques of XP try to help archive these goals. The practices include widely accepted ones, like a rigorous testing process, coding standards and continuous integration. But it also breaks quite radically with common programming wisdom by requiring things like an on-site customer, refactoring as a major component instead of a complete up-front design, pair programming (two developers sharing one keyboard and one screen) and collective code ownership (every one on the team is responsible for the whole codebase and allowed to modify every line of it). It is this mix of proven techniques taken to the extreme and new approaches presented in the book that Beck claims creates a special synergy which leads to a more successful and less strenuous software development process. The author puts forward very convincing arguments for why and how these synergetic effects occur and presents his personal experience using XP on one team as supporting anecdotal evidence. The book is written in an easily readable style and contains lots of sometimes funny anecdotes and quotes. And although it obviously is about the author's pet idea I didn't find it preaching, but rather refreshingly enthusiastic and energetic.
Unfortunately I have to admit that I haven't yet personally experienced all XP techniques in practice, main reasons being that it's very hard to convince management of it's merits ("What?! Two programmers on one keyboard?! No way!") and to get all team members willing to try something new. Maybe if they'd all read this book it would be easier...
In the unlikely event that the ideas don't intrigue you, you still have to buy this book to know what all the hype and controversy is about.

According to Ken Back, Extreme Programming (XP) is a discipline of software development that is based on 12 practices. Most of the programmers out there have exercised some of these (if not all) XP practices for a long time, so these may not be new stuff to them and in software development, in general. However, using them as a guideline for a project is what makes a programmer an eXtreme Programmer. The book is very easy and fast to read. Take a look at it, you might improve your existing and learn some new programming skills. I would say, one of the strongest points in this book is testing. Testing is something I would, most of the time, like to pass on others or leave as a final step in the development face. Ken suggests to write the test first, and test your code at all times - think about it. Another valid point would be simple design. A program written with XP is the simplest program that meets the requirements. Other practices include: planning process, small releases, metaphor, refactoring, pair programming, collective ownership, integration, 40-hour week, on-site customer and coding standards. Enjoy!