Kent Beck | Cynthia Andres
1 not found - the silver bullet
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! :)
2 Embrace Change Again
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.
3 Quick and Solid Intro to XP
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.
4 Too emotional for it own good
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.
5 An expanded vision of XP
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.
6 It is about the Journey not the destination
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.
7 This is what a 2nd edition should be like
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.
8 Not just for programmers!
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.
9 We're growing up
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.
10 Down to earth, common-sense values, principles and practices
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.
11 A must have for an intermediate programmer/developer.
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.
12 eXtreme buzzwording
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.
13 Extreme Bull
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.
14 A work of fiction
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.
15 Embrace change
"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.
16 Profound and Cohesive
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.
17 This book shouldn't be useful
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".
18 Concise yet thorough explanation of XP
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.
19 A good read
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.
20 Great book and a Successful Philosophy
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.
21 Embrace Change!!!!
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"
22 Very enlightened and enlightening
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.
23 Hackers! Salvation is nigh!!
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.
24 A picture is worth 1000 words
#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.
25 Interesting and informative reading
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.
26 Good quick introduction to subject.
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!).
27 Programming Malpractice Explained: Justifying Chaos
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.
28 Glosses over the negatives
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.
29 Slim volume is a good primer on a lightweight methodology
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.
30 Not Software Engineering.
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.
31 radical views on software development, food for thought
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.
32 XP - Highly recommended reading for developers
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!
33 Concise and Useful
I started the book y'day, and by the time I finished reading the first few pages, I could draw parallels to my previous Work Experiences. The book is very clear and concise, and presents facts as they are. The XP paradigm is very useful for small to medium projects of 5 to 30 pple spanning around 3 to 10 mnths. The best part seems to be the emphasis on Testing as an Integral part of the Development and Communication are known facts too.
Overall, I would give this book a thumbs Up, must read for all individuals, who have worked in small to Medium projects.
34 Useful even for the unextreme
Extreme Programming Explained is a great book even for those who don't care for extreme programming, because this book explores issues which are fundamental to programming. It then shows how extreme programming attempts to address the issues. Thus it will make you think, and likely suggest improvements to whatever methodology you are using. Also, if you don't know what extreme programming is, this book is an excellent introduction.
35 Most important software development book this decade!!!
I LOVE this book. The first time I heard of this book, I thought my buddy was joking. The title conjured up images of programmer's jumping off bridges with laptops. Needless to say, I did not read the book then (a big mistake). Later, I read it, and I really enjoyed it.
My feelings are that this is a good book, but it is not complete. It introduces XP, but it is hard to apply XP with just this book. In my opinion, you need the book "Planning Extreme Programming" by Kent Beck, and Martin Fowler and this book to start really implementing XP.
We implemented XP with just those two books.
Don't worry, they are both small books and you could read them both in a weekend.
My observation about XP:
Pair programming is a tough concept to get and sell, but it can really help a team quickly grow in leaps and bounds! It helped our team a lot. We were amazed since everyone including myself was a bit skeptical about pair programming. I could go on a long time about the benefits of pair programming.
Continous Integration (CI) and automated testing go hand in hand with refactoring. Without CI and automated testing you loose liquidity in your code base, and it is hard to add new features. Your project becomes rigid, and brittle without CI and automated testing.
There are other key points I could go on and on about.
This book is the most important software development book in the last ten years. Even if you cannot apply XP where you work, you should at least know what it is all about.
XP has evolved since this book was written and I look forward to Kent Beck's next edition of this book (if one is in planning).
Why are you still reading this? Go buy a copy of this book already.
36 Good Book
I bought this book; and believe me, it's a good guideline to Extreme projects. You don't need experience to read this book. It's an excellent teacher about practice reviews and explanation.
37 A Serious Programming Discipline to Consider
Extreme Programming is a software development discipline. XP can use any number of design methodologies to achieve its goal of software delivery: UML, Use Case, Objectory, Object Oriented Programming, or CASE to create simple design. XP does not limit the developer to any one design methology or any orignal design. Design is expected to change as the application is being built. I read the book and considered Mr. Beck ideas seriously. The practical implementation of the XP principles makes sense.
XP creates a team relationship between management and development. Managers uses simple schedules, scope, and design documentation. XP represents a shift in the detail of control given to a project manager. Managers plan resources for the project and facilitate communication with the customer. The success of XP depends on the ability to predict when work will be done and what work will be accomplished. XP decreases time to develop, decreases risk, and increases likihood of software application deployment.
XP advocates four values: simplicity,communication, feedback, and courage. These values are endorsed by XP as values that decrease time to deliver and increase the quality of the application. These four values are like the proverbial guideline to creating good software and solid long term relationship with the customer.
XP focuses around onsite interaction with the customer. Customers are encouraged to write business stories and provide almost real-time feedback to the developers. Developers use the business stories to bridge business requirements into technical requirements and designs. Communication and good relations develop between the developer and the customer. Customer feedback drives enhancements to planning, design, coding, and testing. Small and integrated releases are created. The team approach encourages continual improvement to the application design. Customer's set priorities and drive requirements based on business decisions. The end result is the customer steers the project. Customers focus on features that the developers are steered to develop. Developers use the business stories to create simple designs. XP empowers the developer to use simple designs and specifications to code. Application value is maintained by small releases, integrated product releases, and application comprehensive unit tests.
XP believes in building code incrementally. Prototyping is useful when verifying design and business requirements with the customer. Code is used to express ideas between developers. Coding standards must be established among team members. Code readability and ownership is managed by the members in the team. Code is collective owned by members in the team. Coding practices must be consistent among the team. Standards minimize confusion. XP encourages developers to refactor design and code to improve effeciency. Refactoring removes inefficiencies, creates reusable code, and removes redunancies.
XP migrates legacy systems incremently into new designs. The book presents an interesting case study illustrating how the author migrated a legecy system over a one year period of time. XP maintains application value by changing content without adversly affecting functionality.
XP builds quality into the application. XP believes in paired development. Two developers working together are more productive than two developers working independantly. Paired programming gives the team exposure to a wide range of experience or knowledge specialization. Pair programming allows developers to partner with individuals who have knowledge about different portions of the system.
XP believes in building unit tests as a part of the application. If a unit test can be coded then time is taken to build it. Unit tests create a feeling of confidence about changes made to the system and the reliability of the system. XP encourages developers to build quality into the application. XP encourages developers to document code. Documentation helps in the maintenance of the code. The long term cost of maintaining the cost is contained and remains marginal. XP seems to advocate that long term cost of maintaining the code will not become the most expense portion of the life-cycle of the code. Developers are encouraged to gain a fervent commitment to unit testing.
XP encourages developers to integrate multiple times during the day. The application is fully-integrated many times through the day. The unit tests are used to make sure the integration worked. Rapid integration ensures that all components within the application have well defined and well known interfaces.
38 Extreme Programming - CMM Principles
One of the most interesting aspects of XP is the focus around metrics. Advance levels of CMM can be facilitated by using XP as a development house standard for the following reasons: 1. Reduction of code complexity 2. Quantitative measurements to predict bugs and defects 3. Statistical models to measure code development time. 4. Inventory Itemization of each component into packages through reuseable components.
39 Absolutely Useless! So is CSCI477.
This book is absolutely useless. The methodology taught is not "extreme", but rather ridiculous...His techniques will never be applied in actual software engineering, as they are completely impractical. For half of the ideas that are practical, they are simply common sense. Such as the 4 values: communication, simplicity, feedback, and courage. Every decent software engineer practices these values. In addition, the author fills up pages by telling stories of his childhood and other needless tales in an attempt to convince the reader that the techniques explained, truely work.
Don't waste your time or money. You'll only be aggravated once you open this book
40 Enough to give you a flavor, but just...
This book is just enough to give you a flavor for extreme programming, and to tempt to implement it. It will help keep the embarrassment wolves at bay, but it's not enough detail to actually implement something. This is manager fodder (it's short), but it's a good intro. For details, check out another XP book.
41 Good Introduction, but Needs More Teeth
Kent Beck's book does a good job of synthesizing a lot of programming concepts and putting them forward as a coherent methodology. The book is deceptively easy to read, though that's not necessarily what I look for in a book on theory and methodology. I look for a challenge, because that means I'm learning something difficult.
As it turns out, the difficulty is not in learning XP concepts, but putting them to work in your everyday software development process. Here Mr. Beck's book falls way short. To fill in the gaps, I recommend Rick Hightower's "Java Tools for Extreme Programming"--it gives you detailed information for coding and building tests using open source tools. The books complement each other and together present a complete thought on XP development.
42 Great introduction to XP with practical examples
In this book, managers, developers, interaction designers, and methodologists will all find a fresh perspective on the software development process, XP (extreme programming). At first, the usability world may look upon the ideas presented in this book as not only extreme, but also completely opposite of what they have found to be true with other more traditional methodologies. In fact, as you study the principles outlined in the book, you will likely find that they are simply a minimal instance of more traditional methodologies such as RUP (rational unified process). This book provides a clear and concise overview of twelve core 'best practices', which comprise XP. It then provides examples and techniques for implementing and promoting XP in a typical development environment. The XP process outlined may not be right for your team or project, and the author acknowledges this early and often throughout the book. Nonetheless, many teams around the world with 4 - 12 developers are achieving excellent results based on the principles outlined in this book, proving that XP is more than just undisciplined hacking or 'cowboy coding' without regard for architecture or usability. As usability practitioners, we are exploring ways to integrate usability successfully into projects adopting the XP process. Unfortunately, the book makes little mention of how to accomplish this critical step in delivering usable software. On a positive note, usability and XP share the common goal of not overdesigning your system. The book is a good starting point to discover if XP is right for your project and team or to take some of the principles outlined and apply them to your existing development practices.
43 brash new approach
Just the testing and integration technique alone is worth the price of this book! As he says, this is probably the only part that you can take by itself. If you don't read anything else in this book, read the parts that have to do with testing and integration. These 2 elements are the cornerstone of his entire approach. The rest depend heavily on each other and must be taken as a unit.
The theory here is exceedingly simple, but just like dieting, it takes discipline and persistance, and (as he intimates) maybe even sacrificing an odd person that won't "fit" with this management philosophy. Although I would probably not copy every stylistic element of Beck's approach, this makes a lot of practical sense. He is realistic in that this is geared toward a somewhat narrow audience with medium-size teams.
44 Good introduction and overview of XP
Not a bad book for an intro to XP, but don't expect to be an XP programmer at the end of it. XP seems to be one of these classic C vs. C++ and C++ vs. Java debates. To be honest, I don't like all the points of XP, but this book was well written to explain all the points at a high level.
Managers, developers and architects curious about XP should pick up this book for a good review. A bit long winded at times, but the content makes up for it. Again, don't expect to be an expert after reading the book, but expect to understand the general principles of XP. A must for anyone considering implementing XP in their development environments. You might just change your mind after reading it, or only take some of the principles and apply them to your existing design and development cycle.
45 Use it from the other side
It's always constructive for an engineer to dive into reasonings that deeply diverge from one's viewpoint. This book presents a good guide for XP advocates, I guess, but also is a valuable resource for methodologists and software project managers looking contrast and enrichment of their own ideas. Strongly recommended.
46 OK general summary of XP
I find the authors style rather long winded. I wish he'd get to the point and not be so chatty. The book provides a good high level, but very general overview of XP.
If you want to learn what XP is about this isnt a bad book. It doesn't take too long to read.
Many reviewers have rated this book poorly because they dont agree with XP. Thats a seperate issue. As a book it fulfills its purpose and explains XP. Be aware that these XP books tend to regurgitate a lot of similar general information. If you read the others in the series (as I have) you will be disappoined with how little additional information they add.
47 I paid half price
and still felt the book wasnt great. Had I spent [the full price] I'd be annoyed. It could have taught the basics of XP in half the pages. The information is ok, and the book could have been a 3 star book, but its too wordy.
Save your money and read Extreme Programming Installed, dont read any others in the series. They all repeat themselves.
48 Well, duh !
To summarize :
A lot can be accomplished with a small hand-picked group of people who are emotionally stable, secure, honest, and communicate well who have a nice work environment, lots of feedback, and a diligent but benevolent boss.
Well, "duh!" Under those conditions *anything* would work. The author pretty explicitly rules out most real life situations at the end of the book.
If these principles of XP are a revelation to a manager, that manager is so far in the hole that they'd better stick with traditional management structures before they do real damage. Consultants can look for business restoring traditional structure to many groups in 2002 .....
49 Your Next Job Interview Will Ask About Your XP Experience.
There are four books about eXtreme Programming, and this one was the first. If you still believe in paper books, buy it, but paper books are not really an eXtreme form of documentation, are they? You can learn a lot - and chat with the author -...which is also the world's first Wiki website, so get the book by Cunningham and Leuf at the same time...
50 The best of the serie for a good explanation of XP
If you want to know what XP is, and the philosophy behind XP, then this book is the best of the collection. It is very well written, concise and easy to read.
51 anecdotal and sometimes silly
XP has some good ideas, but this book could have been reduced to a paper by removing some of the silliness and the many anecdotes.
52 Best Commercial Practices
What do you want me to say? This book is but one of a series. It is not a panacea for all your ills. It only talks about developing quality software when you're under the gun. My colleagues agree that these guys put together the best commerical practices of the past 20 years into one adaptive methodology. The cool thing about this is that you don't have to impliment the thing en todo to get the results you want. Find what you like and start there.
Overall I found this book a delightful read. The chapters are short, like XP's iteration cycle. Short is sweet when you're an over-worked programmer like me. At first I was underwhelmed by this approach, but it works! The annotated bibliography in the back of this book (and others in this series) helps understand the author better and give you context.
This book offers practical advice.
53 Excellent , a quick read
Excellent book for software developers and managers alike. This short but insightful book can be read in a couple sittings. The simple, practical ideas can be put into use immediately. Order it without hesitation.
54 A great overview of a true software engineering approach
I believe that XP is one of the most important breakthroughs in quality-focused development in the past decade. It is a language-independent approach that embodies what is best in software engineering, project planning and control, and attention to quality.
This book is a fast overview of XP and should be required reading for any development manager who wants to get control of cost, schedule and quality. Despite its small page count, it covers all of the key points and will demonstrate to those who are put off by the name, "Extreme Programming", that this is a viable approach.
As I read through this book I saw a lot of parallels in the author's description of XP to some of the best practices and key process areas of the capability maturity model. I was especially surprised at how close XP is to Watts Humphrey's personal and team software processes. These similarities show that XP is a serious software engineering approach and a good fit into companies that have invested in improving their capabilities through attainment of the higher CMM levels, software engineering process groups, etc. Indeed, the metrics that are collected and used by XP practitioners will feed valuable data into an SQA group for transformation into meaningful data for process and quality improvement.
Don't let the title "Extreme Programming" or the short page count of this book deter you from taking it seriously. Mr. Beck clearly describes XP and amply proves its value in this brief survey. If you want to see just how serious XP as a software engineering and project management discipline, read this book, then get a copy of Watts Humphrey's A Discipline for Software Engineering. I give this book 5 stars and my highest recommendation.
55 Simple and elegant introduction to a fast paced methodology.
Extreme Programming (XP) is an interesting concept-- I haven't decided if it's completely feasible or not, but it certainly is interested. Beck outlines his methodology in a very simple and elegant manner. The book is light-reading,b ut never childish.
XP promotes several worthwhile concepts-- collective owenership (if you find a problem, you fix it, you don't find the owner of the problem), authomated unit testing (write tests once, run them everytime you make a change), heavy communication, and severe flexibility.
The element that most people bite on beyond this is pair programming-- two programmers side by side working on one problem. Another reviewer felt that programming requires a certain depth of concentration to perform, and that a second body could be deterimental to this. I tend to disagree, but I also have a very light-weight, on-the-fly style in my software development style. But then again, I'm a jazz musician writing code, so that only makes sense. :)
Even if you don't embrace all of it (and I'm still not convinced on some issues, like pair programming), it's a worthwhile read for the unit testing bits alone.
56 Do it to the extreme!
Kent Beck has put down the outline for a software development methodology that we heuristically employ in tight situations. While I read this book for the first time, I was going "Hey! I do this all the time!.. He has succeeded in putting a name tag on my hunch." almost in every chapter.
The word "extreme" turns off most managers, so you have to feed 'em the information using force if necessary. >:-=[
The "extreme" is actually very reasonable: if it's good, go to the extremes to do it, if it's not, go to the extremes to avoid it; eg., if code reviews are good: do it all the time. Some ideas can be overdone, though, watch your waist line when you keep food around the project site ;-). (I am still trying to loose the extra 20kg (~40pounds) gained during my first XP project)
Some of the ideas are not easy to live with for the "more organized". Most managers I know would wake up a couple of times a night in sweat if they were working on a software without their long-term plan (some previous commenter declared some of the ideas downright dangerous). All clients think they are cheated out of a professional effort to get their software done when you do not a supply a detailed long-term plan for the completion of the project.
That, you have to put up with until your first XP project finishes.
57 A Not Fully Thought Out Developmental Methodology
This book is an easy read and does have some good ideas such as: having a dedicated tester for each XP team, and writing tests. However, I felt that the author's main assumptions such as flattening out the change curve and ideas such as refactoring and allowing for changing requirements throughout the life of a project were both unsupported and even dangerous.
The author, Kent Beck, conflicts himself several times on the issue of the flattened curve. In the beginning of the book he states that using Object Oriented Design and programming code in a flexible manner will allow for requirements to change without an exponential time increase in reprogramming/refactoring. Later, in his book, he states that the programmer should write simple code for simple, short specific requirements and nothing further, in short, not account for future change or flexibility. This avoidance of flexibility blows his argument of a flattened curve away.
Any programmer or manager who has survived a major project knows that changing requirements, especially near the end of a project, means lost time, perhaps even severe lost time due to redesigning...etc. In addition, daily refactoring, as supported by the author also means that code is constantly being rewritten, again causing lost time. A manager cannot allow for such inefficiencies when deadlines have to be met. In my view, if code is properly designed first, taking into account the full requirements of the task, refactoring should be unneccessary.
Beck strongly supports pair programming, but fails to understand that programming requires deep concentration and is not best done with someone staring over one's shoulder or talking in one's ear. In my view, pair programming can be replaced by creating a team atmosphere and encouraging or even requiring programmers to share their designs before writing code so that other programmers can offer input for improvement. Finally, Beck does not support programmer documentation. This is a huge blunder. Any programmer who has faced the task of maintaining undocumented code knows that documentation is a must.
Overall this book left me wondering if the author really understood programming or had actually headed up any successful projects. To me, the idea of Extreme Programming as explained by this author presents a methodology which is both inefficient and insufficient. A better book for software development and management is 'The Dynamics of Software Development' written by Jim McCarthy.
58 Some very good ideas and some questionable ones
First off let me say that this book is well written. Whether or not you agree with the ideas I do not think that you will find a better presented description or argument in favor of the methodology.
The book has a lot of plain common sense (which is not really all that common): Work with simple designs and short release cycles; build testing into the development process; do integrated testing all the time; always get someone to review the code design and check the final code.
My biggest complaint is the attitude toward documentation - namely that it is unnecessary. What happens when the program completes all the tests and the design team disbands to work on new programs? A few months later the client is prepared to pay for enhancements. I know that when I move on to a new project my memory of the previous one evaporates. I sure wouldn't want to have to reverse engineer the program specifications from the test plans. The good news is that the documentation need not be very complex. A few data flow charts do a good job of giving the big picture. In-line documentation is not difficult once you get in the habit of doing it as you code. There should be two levels of in-line documentation - one for someone who wants to just make use of an object and one for someone who may need to make modifications. The higher level of documentation is also good for code reuse. Why bother writing something new if code already exists that does what you want? The detailed level of documentation helps to answer the question of how big a procedure should be. The documentation should read like a simple story; it should not take more than a minute or so to get a general understanding of how the procedure is put together. If it takes longer the procedure is too complex.
I recommend reading this book for both programmers and managers. Just keep an open mind for both its strengths and weaknesses.
59 Well Thought Out Developmental Methodology
While short, terse, and delightfully well written, Kent Beck has put together a book which describes a carefully thought out and revolutionary approach to software development.
You wouldn't be sitting there reading this review unless you were already perplexed by the difficulties of traditional waterfall and phased development models. Those of us that have lived through countless mega-million dollar corporate efforts that have suffered from poor code and misunderstood design have known for a while that something is wrong with the paradigm, but we are too willing to blame the problem on customers or managers to consider that we might have been doing it wrong.
Beck offers a very effective, rapid iteration model that really can produce working results in short order. This is based on a set of practices, some of which are a bit surprising, but which work together quite well.
Beck proposes that business drivers, coupled with technical estimates, used iteratively drive the planning. He emphasizes small releases, simple design, and a coherent system metaphor. Automated, continuous unit testing, based on requirements builds a test set which encourages refactoring of the code. Refactoring plus frequent (even daily) system building and testing helps to reduce late project test crises.
Beck feels that pair programming, a limited work week, and a sense of collective ownership build effective development teams. Other important factors are the presence of on-site customers and good coding standards.
Whew! Sounds like a lot. But Beck makes sense of it all, and presents his approach clearly and with winning style. This is a very easy read, and one that may change your whole approach to development.
60 Most of these techniques are essential in RAD-environments
This book didn't change the way I run projects, but I picked up a few techniques and tips which will improve my development skills, mostly in the area of programming and not as much as a project manager.
Although a provocative read on the standard cycles and techniques of development this book does not offer that many new aspects of how to do things for the seasoned developer. Anyone who has used a rapid application development method will quickly recognize several of the techniques describes in this book; eg. simple design, small releases, on-site customer, etc.
However if you have not, and are a bit open-minded, this book is a good read. I especially liked the idea about pair programming, although I don't think it should be used extensively through a project, but rather in certain areas. And writing tests b-e-f-o-r-e you program, to ensure every aspect of a function is covered, is also a very good idea (but it will be very hard to persuade programmers to do this).
61 Interesting!
After years of developing software and praying for the day I get to actually do a project right: spending 60% of the time designing, up front, and then spending 25% of the time cranking out the code and another 15% testing - to deliver the perfect software package on time... I never really thought that maybe we were just going about it all wrong.
Extreme Programming (or XP) is a conglameration of ideas about software development that aren't new but are proposed in a coherent manner to actually create a new methodology. The fundamentals are: always code to the existing design - throw out code that anticipates future needs, never work overtime (unless it's for a very specific reason), code in teams so there is 100% code review, always end the day with a working build. The methodology is much more realistic (according to my experience) and Beck provides a great introduction to it.
62 The "gossip magazine diet plans" style of programming.
This book reminds me of the "gossip magazine diet plans", you know, the vinegar and honey diet, or the fat-burner 2000 pill diet etc. Occasionally, people actually lose weight on those diets, but, only because they've managed to eat less or exercise more. The diet plans themselves are worthless. XP is the same - it may sometimes help people program better, but only because they are (unintentionally) doing something different. People look at things like XP because, like dieters, they see a need for change. Overall, the book is a decently written "fad diet", with ideas that are just as worthless.
63 If you're really that curious about XP.....
I would recommend this book to any software modeler-geek that just loves to read books about the software development process. Certainly XP is not a lazy alternative to UML. If you are new to programming I would pass up this book without a second thought. I do not care for XP, so I could'nt recommend this book to anyone but the serious, serious software development process GURU who wants to have read everything. But if you're really that curious this book will (try) explain it to you.
64 Excellent Read
This has been my favourite book which I have been carrying around. The size of it is just nice for reading on the bus or on the train.
This book describes about what XP is, without being biased. It is enjoying to see how several simple concepts are being put together to make software development a joyful process for everyone, the programmers, the management as well as the customers.
I have been advocating XP in my company without much success. If only they can be less sceptical and less biased and pick up a copy of the book to read, I believe everyone would benefit from it. I urge you to do so also.
This book is IHMO one of the best book I have ever read.
65 a refreshing alternative to traditional methodologies
Many see XP as the nemesis of the Rational Unified Process when in fact these two methods when combined provide the synergy needed to boost your software development projects to a new level. eXtreme programming explained is a very good introduction to XP, an innovative method of developing software that is beginning to revolutionize the previously held thoughts that a development method has to be a bulky and heavy process to implement in the new wave of high tech projects. XP is a methodology that is based on making the process of programming complex systems as simple as possible while at the same time maintaining quality through the use of unit testing and iterative integration throughout the development process. Of all the great ideas that XP presents, probably the most significant is the notion that the cost of change curve has gone from an exponential curve to one with an initial high rate of positive change and then a flattened curve with a decreasing rate of change. Beyond this being a very strong statement backed by great minds such as Martin Fowler, it is something that goes against what many other great minds have come to expect from software development. This is based on the fact that new programming languages and environments along with better design principles such as component based development allow software to remain resilient to change, thereby making that exponential cost of change curve a factor of times past, so much for our Software Engineering classes in college.
So in general, XP presents some new ways of thinking for engineers who are used to more traditional ways of developing software. XP explained is a good book to get you introduced into the methods but not nearly enough to get you started in XP projects, for that you'll have to check out one of several web sites with more in depth examples and case studies that will help guide you through your own projects.
Never fear though, there are a couple of books coming out soon to help you out in implementation details, you can get them right here on amazon, just search for extreme programming, I've read the final draft for one of the books and if you are at all interested in XP these books are must gets. I also highly recommend reading " The Rational Unified Process, An Introduction, second edition", also available here on amazon. This book provides a different perspective on developing software, one that must be taken with a grain of salt and an open mind, much like XP. I recommend anyone interested in improving their development process to try and look at as many methods as possible and try to see the similarities in them to get a better perspective on what makes for a good process method.
For those of you who need help getting a handle on these subjects, feel free to drop me an email and I'll be glad to help anyone out and guide you to more information online.
66 for all developers
This book is for an understanding of XP, not an how-to book, as author explains. Book is organized of short chapter(3-4 pages), each makes you think of problems you previously had in software projects.
Author explains the problems we all have in software projects very well and states easy solutions.
I think this book is a great introduction to XP.
67 Explained is the key word...
This book does a very good job of explaining what eXtreme Programming is. It does not promise to provide all of the details of successfully implementing and using XP (which is stated in the Preface), but it does give a very good introduction to XP. If you are considering XP, this is a good book to help you decide. Perhaps, other books in the Beck/Gamma series would provide more details (I haven't read any others yet.).
68 Read this book with an open mind
I love this book. When I first read it, I agreed with many points discuss in the book, but I was also skeptical about many points Kent was trying to make. Overtime, I noticed that a lot of problems in my previous organization can be solved by adopting methodology discussed in this book. I suggest anyone reading this book to be open minded and notice how XP can solve problems in your organization. I believe ideas in this book can make any software development group better.
69 Inspiring Reading
Having worked with numerous development process models, this book cuts through the bureaucracy of traditional models and introduces an inspiring alternative. None of the process steps are actually explained in detail. Read Rational's Unified Process, if you need details. Extreme Programming Explained concisely covers just enough to inspire - nothing more, nothing less, and it does it well.
70 Good Book for Conceptual Knowledge
My goal upon buying this book was to gather a good "solid" overview of what XP is and some back round regarding this methadology. This goal was accomplished. However, this 166pg book could be a narrow 30. My suggestion is to skim the book in a book store for about 30 minutes.
71 Poorly written
The book is a summary. Too many assumptions are made of the components involved in the XP model to give the readers a good base to use. There are some good ideas but not enough to actually implement the process.
72 Where's the beef?
Chapter after chapter I kept thing that the author would get to something substantive. He never did. Not one example. Not one piece of concrete evidence. He had some good common sense ideas, but they are all presented in such general terms that they are self-evident. The author makes grand assumptions and goes on to explain (in generalizations) his theories which are based upon these assumptions. I often envisioned the author standing on a street corner proclaiming the end of the world or espousing the "scientific" basis of creationism while exposing his complete misunderstanding of science and his willingness to ignore facts that disprove his assertions. This entire book is written as if it were an introductory chapter. It reads like a psychology text - a lot of verbiage which hides the fact that the text has almost nothing to say.
73 A new approach to software development
This approach to programming was much bandied about and a little controversial at a software engineering conference I recently attended. Beck's premise is to take proven good practices in software development and max them out:
- if code reviews are good, do code reviews constantly by having another programmer look over your shoulder.
- if testing is good, write your test plans first and then test each time you implement another feature
- if integration is good, integrate almost constantly so that the system always works
The underlying premise is that the old, familiar cost curve that says it costs a thousand times as much to fix a mistake in the testing phase as in the requirements phase is no longer accurate: we have much better tools now than when that curve was formulated, we're living in Internet time, and the customers don't know what the heck they want anyway. So we might as well go ahead and try to give them something, then fix it up later, rather than trying to divine their goals now.
The problem I see with this is that there's not much time allowed for doing analysis and design. Beck specifically counsels against trying to anticipate capabilities, but if you know what you're doing, anticipating capabilities can save you a lot of time down the line. (His rejoinder is that it can also cost you a lot of time in implementing and debugging features that don't work and may never be used.) No matter how clever you may be, doing design as you code seems to me to be one cut above the worst sort of hacking.
Still, there are some marvelous ideas in here: pair coding sounds intriguing, writing test plans first is a must-have, and I've always held the position that the system should be constantly integrated, that there should never be a big push at the end to get all the pieces to fit together.
He also has other, related advice: developers should not work overtime for more than one week in a row (that's a way to become less productive, not more), you should have a customer representative onsite with the programming team to answer lesser questions about how to implement capabilities, and so on.
In summary, this book is very worthwhile for anyone who wants to improve their software development practices (and who doesn't have problems with their software development practices?). It's particularly good if you're in an environment where the customer wants a quick response to what they want when they want it even as they're not sure what they want. I wouldn't recommend adopting the approach wholeheartedly and automatically (and neither would Beck), but take what makes sense and go from there. As Beck himself says, figure out where your biggest problem is and adopt XP practices there first.
74 Excellent Thought-Provoking Ideas
This is one of the most thought-provoking, interesting software development books I have read. At its heart is the idea that the traditional exponential software lifecycle cost-of-change curve doesn't necessarily have to be, and if we "embrace change" as the book's subtitle suggests, we can roll with the punches, flatten the curve and deliver solid software sooner and in a much more satisfying way. Kent Beck's style is very easy and enjoyable to read, and very practical and realistic. He knows programmer psychology and it shows, with the whole methodology working with the programmer, not against him/her. Even if you don't want to or can't follow the whole extreme programming model, you will certainly be able to pick up pieces of good advice to improve the way you currently development software.
75 Only the pair programming concept is new
Anyone with a decent Software Engineering background will see there is really not much new in this book. Sure you should write test cases before coding. But for a complex program you can never try out all the possible user inputs with a few hundred testing cases. It's more important to start with good object oriented designs. Find a book on OO or UML from Booch, Coad or B. Meyer.
76 An excellent but nontheless limited methodology
In an ideal world almost any methology will work and I can't help but feel but that this methodology is also suited to such a world. Extreme Programming concerns itself with the minutae of code development and appears largely to reject the notion of having an overall design. This approach dangerously weakens the concept of a there being a 'Big Picture' into which a system fits and overemphasises the idea that everything can be broken down into small independent units. Unfortunately it does't follow that if the parts work then so will the whole.
Whilst the methodology is at its best in dealing with these small units it is weak on how best these units should be assembled and the combined constructs tested. Unfortuately it is rare that coding level problems affect a project as much as system level ones.
Another problem with this methodology is that it generally ejects the customer from the development cycle. It's all very well going to the customer initially but, if you then pull the shutters down and only seek feedback whenever there is a new version, customer confidence will rapidly drain away. Frequently asking a customer "How does this version look?" doesn't garner confidence.
There are good ideas put forward in the book too. The princple one is that of 'pair programming'. This can be useful when new ideas are being tackled, less so when dealing with the 'mundane' coding. Overall, the best ideas advocated in this book (forward planning, frequent testing, better communication, etc) are actually independent of the methodology itself and when applied as intended with any methodology would produce improvements.
77 An excellent but nontheless limited methodology
In an ideal world almost any methology will work and I can't help but feel but that this methodology is also suited to such a world. Extreme Programming concerns itself with the minutae of code development and appears largely to reject the notion of having an overall design. This approach dangerously weakens the concept of a there being a 'Big Picture' into which a system fits and overemphasises the idea that everything can be broken down into small independent units. Unfortunately it does't follow that if the parts work then so will the whole. Whilst the methodology is at its best in dealing with these small units it is weak on how best these units should be assembled and the combined constructs tested. Unfortuately it is rare that coding level problems affect a project as much as system level ones. Another problem with this methodology is that it generally ejects the customer from the development cycle. It's all very well going to the customer initially but, if you then pull the shutters down and only seek feedback whenever there is a new version, customer confidence will rapidly drain away. Frequently asking a customer "How does this version look?" doesn't garner confidence.
There are good ideas put forward in the book too. The princple one is that of 'pair programming'. This can be useful when new ideas are being tackled, less so when dealing with the 'mundane' coding. Overall, the best ideas advocated in this book (forward planning, frequent testing, better communication, etc) are actually independent of the methodology itself and when applied as intended with any methodology would produce improvements.
78 Post-modern software development
In this slim volume Kent presents a framework for software development (XP) that values the individual, and asserts that this framework actually builds better software faster than the alternatives. Based on my experience using XP I have to agree.
It's often been popular to have software development methodologies the present software development as completing a number of stops. These high-dogma methodologies produce a lot artifacts at each stage. They have been designed to handle an environment where the cost of change was high, and we needed to do all our thinking up-front to avoid later change.
But what if the cost of change wasn't high? How would that affect our behaviour? And do we now have development environments that can radically change teh cost-of-change curve?
It turns out that we do have tools and practices that can radically alter the cost of change curve, provided we change our mindset as well. We can create flexible, adaptive software in environments where both customers and developers are respected and enjoy the work.
"Extreme Programming Explained" is a starting point for anyone interested in embracing this paradigm shift. It discusses the core practices of XP and gives you enough material to start your own XP project. We've done that where I work. Other books will provide more details on XP, but the XP philosophy says introduce something simple and see how it works. "Extremem Programming Explained" is that start.
If you're unhappy with your work environment and think that there must be a better way then you should definitely read this book. But read it even if you're happy as well - things can always be better!
79 A different kind of book
Some books have the ability to get us to think about things in an entirely different light. I found Extreme Programming so. Whether you decide to adopt XP or not, the book will help you think about programming in a new light. You might call it meta-programming. Why do you do what you do? Is there a way to do it better? Books like this are rare.
80 Good discipline for implementation but lack of modeling
Ken expose here very clearly and efficiently a new way to think about process, entirely based on code and hardly iterative cycles. One could say (and I am one of them) that this discipline missed model usage, because the author prefer CRC cards. Nevertheless, the author don't pretend to get the ultimate graal, but simply expose his ideas. I think that there are a lot of good ideas here, especially when you deal with implementation. Moreover, the book is efficient, short with short chapter, and even if you don't buy the author's ideas, you will not waste your time.
81 Great book on one approach to software development
I believe in the "think first, program later" school, but the author Ken Beck makes a strong case for what I call "design a little, then test, then program, then repeat many times" school of incremental programming. The author calls it "extreme programming."
I thought the book was easy to read yet contained very important topics. Even if you don't agree with the author on releasing many small versions of your software, you will find many useful ideas here. At least I did.
I don't fully agree with the author, but I can see several kinds of situations where it applies (where specifications are unclear, for example, which is often). His approach would not be considered prototyping. The approach relies on many software builds, and the use of automated testing to reduce risk and increase confidence in the software.
His comments on options pricing models and software was excellent, but could have been developed more. I think this might have been confusing for non-financially oriented readers.
I plan on using several of his recommended techniques. The only weak point of the book, was that I didn't fully understand how to implement the automated testing that he recommends. This looks very powerful, after he described the ramifications on the software cost curve. I guess I'll have to learn this from another source.
I see that another book is anticipated by the author in December of 2000. I plan on getting that book as well.
Overall, I highly recommend this book.
John Dunbar Sugar Land, TX
82 XP = the Psuedo Revolution
The claim, in one of the reviews here, that this book is going to rank w/the Gang of 4 book is patently absurd. This book attempts through a kind of Jonathan Edwards Fire and Brimstone approach to convince the reader to get its religion, but when you sum it all up, there isn't much religion to get. All the pillars of the methodology have little or no exposition in the book (unit testing, pair programming, constant builds). They are all mentioned and meekly argued for, but none of them are actually examined. Furthermore, I remember quite distinctly reading about pair programming in Larry Constantine's far better Peopleware a LONG TIME AGO!
Let me add one other crucial point here: this book attempts to achieve acceptance with the reader through creating an impression of both an epiphany and validation. I found that a lot of things that were being espoused here are things I've been doing a long time. I believe many people will find that to be true and consequently will like the book because of the sense of validation it gives. However, when I was done, I couldn't help but think about how much more could have been done here! How about talking about actual unit testing examples? Why not talk about structure within groups; it's far too easy to just say everyone should be doing everything. Profiling, for instance, is clearly not something everyone should be doing. Like so many things in the modern world, this is largely a retread wrapping itself in the cloak of a revolution.
83 XP considered harmful
The XP approach to development is just another weak rationalization to explain why hacking is an OK approach. Design doesn't enter in until you've hacked yourself into a corner. While making bold claims, such as the claim that the cost-curve for early versus late changes to a product is actually flat (at least using XP), the key claims relied on in the book are never verified or quantified in any manner. Another annoyance of the book is that it seems to talk about *all* software development, but in actuality really only ever deals with issues of concern to IT organizations. Granted, that is a huge chunk of the industry, but the author never so much as acknowledges other application areas. There are some good things in the book, but only a very experienced engineer would be able to sort them out from the rest.
84 A Must Read For All People Involved with Software
This is a great book on an important subject. It is only 179 pages but more worth than a lot of books with more than a 1000 pages. It is well written. It is a classic. Well worth reading every year for the next years to come.
85 Radical zeal but concise, simple, courageous
No doubt the ideas brought forth in Beck's work will generate controversy. He writes as he preaches, simple and courageous. I read the book in 3 hours and am still thinking heavily about its message. Current technological advances may actually allow his approach to work but it will be a tough sell to any customer comfortable with current methodologies. Beck's zeal is contagious but it comes across as rationalization for the lazy way I want to code. Frankly, what he espouses could be downright dangerous (not courageous) if the test bed environment is not extremely robust. I would have loved more facts and figures behind the one-paragraph arguments. I agree with other reviewers, this is just a large article, not a book, but oh does it generate some radical thoughts!
86 real process for rapid development in a dynamic environment
I develop software in a dynamic (i.e. chaotic) environment where customers are rarely sure of what they want software to do for them. If we were able to completely blueprint a design and have the customer sign off on it, the requirements would likely have changed the next day.
Extreme Programming Explained puts forth the concept that software is and should be very malleable. It seems to be a variant of the spiral development process, with a chief distinction being that each cycle results in an actual integrated, deployed piece of software. A main differentiator is that XP offers a body of complementary techniques and principles that make very rapid development in a changing world possible.
Competition is too great for companies to risk nine months (of time and dollars) waiting for software that may not meet its needs by the time it is delivered. Getting working software in front of a customer in a very short period of time is critical. However, the overhead of proper reviews and testing cycles is usually too much for an ideal 2-3 week spiral cycle. Pair programming and automated tests, two important concepts that XP promotes, are specific techniques that purport to solve this problem.
One other major positive of this development "methodology" is that it centers around the fact that software is developed by teams of humans -- something most other processes almost never take into account. XP is not geared toward teams of hotshot, superstar developers. It instead realizes that most development organizations are a wide mix of capabilities and experience levels -- something extremely important in this age of a severely limited developer resource pool.
A few of the ideas presented are a bit nebulous, but I suspect that's to pave way for the followup books which will go into depth on actual practical application of the concepts. Lacking for me, personally, was a discussion on integration testing and the organizational shakeup that introducing of XP will definitely create. I'd also like to see more documented case studies. Otherwise, the book is a quick, enjoyable read.
87 The Electric Kool-Aid Acid Programming Test
There has been much discussion of late about making the practice of programming into an engineering profession. The current state of programming has been described as being similar to electrical engineering in the early 20th century. (see IEEE Annals of the History of Computing, Vol 19, No. 4, 1997). In that age and our current age there are two camps--one camp believed that there is a scientific basis that can be applied to the 'art' of electrical engineering (Heaviside) and the other camp, the so called 'practical' men lead by Preece, who once said, "I cannot recall to mind one single instance when I derived any benefit from pure theory."
This book ignores evidence of proven programming practices that actually work. Practices that have actual empirical evidence to back up their claims. Evidence that software development can and should be a consistent, predicable endeavor. If you read this book and no other you would not believe that software could ever be an engineering profession.
This book celebrates programmers as craftsmen rather than engineers.
This book has some interesting ideas. The author's writing style is reminiscent of a over zealoted high priest. I guess this is understandable in that no evidence is given and we have to prodeed on faith....
In summary, skip this book and buy After the Gold Rush by Steve McConnell.
88 Good concepts, Bad book
I've been using most of the techniques from this book off and on for the last three years and I think they're quite effective. Like the author said, if code reviews are good, do them all the time (programming in teams). If testing is good, do it all the time. Nothing earth-shattering there but I think this style is much more efficient if you have the right team members.
However, I thought the book was weak. I'd agree with the other reviewer that said this would have made a better article than a book.
If I had paid $30 to read this book, I would have been disappointed. I would much rather have a five page article version I could pass around to other developers.
89 possibly life-altering
It is difficult to say anything about this book that will not sound like crass exaggeration. Let me restrain myself and say only that it contains a readable description of some ideas that I cannot resist investigating further. For a taste of what's in store, use a search engine to find references to "extreme programming."
On the down side, you will definitely have to investigate further. The book is a bit light and brief, a manifesto for a new approach to development. The author is loosely collaborating with a group that plans to publish several books to fill this gap, among them the already published and quite excellent "Refactoring" by Martin Fowler. Beck and some co-authors are at work on a follow-up called "Playing to Win."
90 Purely amature
While "Extreme Programing" has a number of sensible suggestions, the net-effect of it is quite marginal. I read numerous positive reviews and was hopeful when ordering the book, but was rather disappointed in the end.
The prose of the book is quite poor, almost to the point of annoying. Everything in the book is referred to as "Extreme Programming" or "XP" which really nullifies the term. The author also has very little support for most of his arguments, which leads a reader to wonder if some of the ideas presented are mere whim.
If you don't already own this book, then save yourself the bother. There are a number of books along the premise of "Extreme Programming" which are much more useful in the end:
"Rapid Development" and "Code Complete" (both by Steve McConnell)
"The Pragmatic Programmer" (Andrew Hunt).
91 Buy this book!
No, this isn't a programming book per se. However, it's the best book that I have ever found on the process of developing software. I used a similar process to build a product called SalesLogix. It worked and worked well. The idea of building in increments is invaluable and a much better idea than the big bang approach. The team programming concept is also gold. Buy it. Buy it. Buy it.
92 Buy this book!
No, this isn't a programming book per se. However, it's the best book that I have ever found on the process of developing software. I used a similar process to build a product called SalesLogix. It worked and worked well. The idea of building in increments is invaluable and a much better idea than the big bang approach. The team programming concept is also gold. Buy it. Buy it. Buy it.
93 Anti-Methodology Culture Formalised
I have been writing software for 17 years and now realise the past 10 years were cursed by the rise of formal methodologies.
This book provides useful ammunition so that programmers can protect themselves from the chattering classes of the IT Industry and get on with the job. No doubt the Rational Rose crowd will spend millions of corporate dollars in an effort poor scorn on the title.
The ideas presented in this book will be debated for years, let's hope more skilled communicators take up the Extreme Programming baton and publish further titles.
One star dropped due to the shallow presentation and poor organisation, but then a well-structured book from this author would have been almost disconcerting!
94 Radical ideas!
Kent Beck explores some interesting ways of improving the software development cycle. If you are not interested in some big changes, then this book is not for you.
One of the more intersting concepts that Kent is pushing is this book is the concept of programming in pairs. This means that whenever code is written that you have 2 people working on the same computer to write code. My first thought was that this would slow down the process, but Kent explains that it does not actually slow down the process, and it actually speeds things up.
This book contains many radical ideas that would really change the development process. For instance Kent explains that its better to meet the requirements as they exist at the end of the project, rather than the requirements that have been set at the begining of the project.
In a day time when progress is measured in "internet time" and requirements are constantly changing, Extreme Programming provides some usefull ideas.
95 This book has changed my attitude to work
... and has probably been the most influential book I read for some time. Highly readable, Extreme Programming seems to give back the fun to software development that was drained out of it by the fear of touching the code to early.
The main thing lacking is a cookbook on how to apply XP in today's over-outsourced and over-distributed web-development environments.
Who is going to write about this?
96 XP will change what is possible with quality software.
XP redefines the relationship between software developers and their customers. Better said, it defines that relationship when up time now it has been characterized by tension and blaim. XP defines simple rules, and simple roles that allow for better communication and higher project success rates. XP gives Project Managers the tools to measure and manage a project. XP gives Software programmers the tools to deliver a higher quality product.
97 Extreme programming is not so extreme
Extreme programming really is not what the name suggests. In many ways, it is a throwback to the earlier days of programming. When I was teaching at the college level in the decade of the eighties the first thing that we told the students was the classic principle that goes back to the beginning of civilization. When faced with an extremely difficult task, divide and conquer. Works in war, politics and software development. In extreme programming, this principle is applied to the largest of projects. The iterations are parceled into as small a unit as possible, with the cycle being: design a little, code a little, test a little. Something like the baby step approach to software development. In particular, "Code is integrated and tested after a few hours - a day of development at most." However, this must only be a rule of thumb, as there are times when it takes longer than a day to create the code update. Which is what I see as the problem with extreme programming taken to the stated level. In all the stages of development, there are tasks that simply cannot be broken down into the "baby steps" needed for extreme programming. An even better example is testing. Even with a superb design that is heavily encapsulated, it is possible to make a "simple" change that would require days of testing to verify.
Another throwback is simply, make the programmers talk to each other. Note that the word was talk, not communicate. Electronic messages are fine, but humans still transfer information and resolve differences much better when there is mutual visibility. The core of this point is what the author refers to as pair programming, where the tasks are parceled out into teams of two. Ideally, the two will complement each other, where one can code while the other analyzes. All fine in theory. Like so many other theories, it ignores the reality of human nature. If you create a team of two and place them in a stressful situation, there must be a great deal of mutual respect, tolerance, understanding and they must complement each other. If one possesses a greater skill set or more simply, a dominant personality, then the total will not be greater than the sum of the parts. There is also the problem of breaking ties, which will fall to a manager, who may not be as cognizant of the issues as the members of the pair.
The four principles of extreme programming are: communication, simplicity, feedback and courage. Sound advice for almost anything you wish to undertake. However, not everything is simple, feedback is sometimes difficult, impossible or wrong; communication is both positive and negative and courage can get you fired. I have no doubt that these principles will work, but only of they are used as general guidelines and not as fixed rules. It is worth reading, but there are better books available.
98 The Jonathan Livingston Seagull of software development.
It is freedom, on a mission
99 Disappointing
I don't recommend this book for someone on a real OO project of any size. While there are parts of the book that might be useful, many of the suggestions are downright wrong IMO from the many OO projects I've been on. CRC cards are all well and good, but they don't scale to significant commercial projects. Open group areas with desks pushed together is a bad thing, not a good thing. As much as the author wants everything to center around programming, it doesn't. Some thought in analysis and design and refactoring @ that level is more powerful. Programmer pairs is an interesting idea to try (though I think it's taken too far in the book). There are much better books out there (e.g. Larman's OOA/D book; Fowler's UML book) - get them and leave this one on the bookstore's shelf!
100 This book is a great read that even I could understand
At one of Kent Beck's talks I went to, he described Xp in terms of "building software like software" instead of like archetectur or craftmanship or mathmatics or anything else.
Reading this book, though, it would seem that programing is actually like raising kids. You have to start small, use the simplist thing that could posibly work, make sure everyone does only their job, that everyone contributes and no one is overworked. In a very real sense, everything you need to do Xp, you learned in kindergarten. Take turns, work together, if you break something, fix it, none of the concepts are that dificult, which makes you wonder why some people hate it so much. If you really want to learn the philosiphy behind Xp, take a look at his bibliography. It is a magnificent document on it's own.
