Customer Reviews

Extreme Programming Explained: Embrace Change

5 star:		(54)
4 star:		(25)
3 star:		(13)
2 star:		(5)
1 star:		(13)

 

 

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.

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.

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.

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.

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.

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.

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.

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

First, this book is not a reference book but instead more of a story. I look forward to Kent writing a more reference-oriented book that cites examples. Some of the concepts, therefor, are vague and left to the readers imagination; I would have preferred if he talked more about testing as it is one of the fundamentals of XP. That being said, there are some unique changes to the standard approach in development. Most specifically: pair programming, automated testing, story-telling, and last but not least, collective ownership. My first reaction to his concepts were both negative and skeptical. As I read on I saw him explain those the things that always bothered me about current design and development approaches that simply never worked (i.e. designing abstracts for the future is just guesswork and often incorrect after a year passes). As I continued, his ideas went from being odd to pragmatic and began implementing them at the company I'm currently working for. We are now starting to better understand XP, and we are in a VB and C++ environment which makes it even more challenging. My team is starting to embrace the concepts and already are looking forward to pairing up and watching the tests run. Its not clear this early in the project the short-term advantages, but if this pans out I can see long-term being far more flexible than our competitors when we need to steer our product down a new path in order to follow our client's needs.

In this short and delightful book, Beck presents the underpinnings of the discipline of software development called "Extreme Programming", or XP. He tells us why the discipline works and the basics of how to do it. (More books are forthcoming, but start here.)

The book addresses lightweight approaches to customer communication, architecture, design, testing - the whole cycle of software development.

XP isn't for everyone: it is for people who have been and want to be passionate about programming, who want to do a good job in today's fast business environment, who are team players, and who are willing to be disciplined about how they do their work.

Hackery? Hardly. Those who fear that XP is "hacking" have not read or do not understand the book. XP is highly disciplined, including more customer contact, more testing, and more design than most projects ever see.

Required Warning: I'm the "self-proclaimed least" of the folks working with XP and writing about it. So I'm biased.

I'm biased for a particularly good reason: I had the chance to try XP in its purest form, on a project that had been in trouble. I wasn't sure everything would work - and where it didn't, we changed and improved the process. That learning is now in the book. I was often surprised by the way XP allowed a team of ordinary humans to consistently delight their customers.

To get the benefits, you have to do the process. Beck has given us the first volume of information on how to build software better, faster, and with more enjoyment.