Product Description
“In this second edition of Extreme Programming Explained, Kent Beck organizes and presents five years’ worth of experiences, growth, and change revolving around XP. If you are seriously interested in understanding how you and your team can start down the path of improvement with XP, you must read this book.” –Francesco Cirillo, Chief Executive Officer, XPLabs S.R.L. “The first edition of this book told us what XP was–it changed the way many of us think about soft… More >>

Extreme Programming Explained: Embrace Change

5 thoughts on “Extreme Programming Explained: Embrace Change”

  1. A few years ago, Nathaniel Borenstein wrote a fine little book called “Programming as if People Mattered”, which is mostly about user interface design. It’s almost a shame that the title has been used, because it’s also an apt description of Kent Beck’s new book. This is a development methodology that acknowledges that developers matter, and that customers matter, too. And they matter in both good and bad ways: Extreme Programming acknowledges that people have rights and strengths, but also that they have weaknesses, and it works with those weaknesses rather than against them. This is a welcome contrast to most of the mainstream software methodologies, where only the methodology seems to matter.

    Beck and the other Extreme Programming advocates have been in “evangelism mode” of late, and their zeal has occasionally seemed excessive. This book, though, is well-reasoned and balanced. The limitations of XP are freely acknowledged, and Beck argues that in some cases and situations, XP is probably not appropriate. His goal, as the title states, is to explain XP, to help readers understand it so that they can decide whether it’s for them. I think he succeeds completely.

    For such important material, the book is light and easy to read. It’s also short and direct. Spend a day or two reading this book, and then spend a week or two thinking about its recommendations in light of your current project. You owe it to all of the people associated with your project who matter.
    Rating: 5 / 5

  2. 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.
    Rating: 5 / 5

  3. 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.
    Rating: 5 / 5

  4. 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.
    Rating: 5 / 5

  5. 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.
    Rating: 4 / 5

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.