Extreme Programming Explained: Embrace Change

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

The release 1st edition of this book is still considered by many to be the kick start for the growing adoption of a software development process called Extreme Programming. After 5 years, the 2nd edition faces a much different world but also with much different content and approach. The world has learned much and so has the author. I'm glad to see that this 2nd edition reflects that development. Beck has revised his thinking throughout the book. Some obvious examples include his current preference towards using ideal time over abstract time units in estimating, the fifth value among the initial four, the new set of principles, and the rehash of the practices. Extreme Programming Explained is not a detailed how-to for adopting the process it describes. Actually, it doesn't really describe a process at all. What it does describe is a system of values and principles and a set of practices to support these. Even though Beck does give each practice (divided into primary and corollary practices in the 2nd edition) their share of explanation, the focus is still strongly on the "what" and "why" instead of the "how". As someone who has read a dozen books on the topic already, I was delighted to find almost every page to provide something intriguing that either created or challenged my own thoughts. Especially the latter half of the book, dealing with topics such as TOC, scaling, Taylorism, the Toyota Production System, and the hot potato itself -- offshoring -- offered a lot to think about. This is what a 2nd edition should be like, every single chapter reflecting new insight gathered over the years.

This 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 worksThe 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.

Some people will attack it as being a return to cowboy coding, which it isn't. It is instead a new methodology that focuses on creating tests before you code, working in pairs to get an instant code review and other innovative ideas.The methodology seems like it would work with small teams of well motivated people, but it probably wouldn't work in cases where morale is poor (ie: bad management) and it remains to be seen how it will scale up to larger teams. Another part that seems weak is the transition from a rapidly growing system to a stable system with only maintenance work being done. This part is glossed over largely because the author doesn't seem to have had much experience with this (he mentions never being on such a project).Lastly, the question of how big the effect of the Smalltalk origins of the methodology are make it hard to judge their applicability to a non-Smalltalk dev team.

This book will challenge your preconceptions about how software should be developed. It is a direct challenge to the old way of software development where we talked about "Freezing Requirements". It asks us to use the power of Object technology to Embrace Change instead.Extreme Programming is a methodology that allows developers and customers to work together in a synergistic manner. It takes the idea of Incremental and Iterative development and shows how to effectively apply it in the real world to produce business value.This book explains how small teams of developers can work together using a set of self reinforcing practices that enable great productivity and quality.It is about time that a developer has written a book that questions the high ceremony, document centric software development methodologies. What we need is a balance between developer friendly practices such as testing your ideas out using code (often derided as "hacking"), and the need a business has of knowing that their investment in the software will pay off. Not all problem domains will benefit from eXtreme Programming, but that is true of any methodology (and at least eXtreme Programming is up front about the need to check if the process is applicable).To those critics that accuse this book of promoting hacking and ignoring all we have learnt about how to develop software, I suggest that it is time to apply scientific thinking. Try some experiments with your current process, then try some eXtreme Programming experiments and see which give the best results.In summary, a Great Book, Buy it, Read it, Think about applying the lessons of eXtreme Programming.