Extreme Programming in Practice [Paperback]

James W. Newkirk (Author), Robert C. Martin (Author)

Book Description

Series: XP | Publication Date: June 5, 2001

Extreme Programming (XP) is a lightweight methodology that enables small teams of developers to achieve breakthrough productivity and software quality, even when faced with rapidly changing or unclear requirements. In this new book, top object-oriented consultants James Newkirk and Robert Martin walk through an entire XP project, chronicling the adoption of XP by a team that has never used it before. Along the way, they show how to overcome the obstacles facing XP adopters, and present realistic XP best practices virtually any development organization can benefit from. The case study in this book is real, driven by the needs of a real customer. The artifacts, code, user stories, and anecdotes are all real, drawn from videotaped meetings throughout the project's development process. The result: an exceptionally true-to-life narrative, complete with mistakes and false starts, and reflecting the ebb and flow of a real project. For organizations considering XP, this may be the most realistic and useful guide ever produced. For project managers, developers, software engineers, XP customers, and upper-level managers.

Editorial Reviews

Amazon.com Review

For any organization or team considering adopting the Extreme Programming (XP) software methodology, Extreme Programming in Practice provides a downright fascinating glimpse of XP in action for a small real-world project. Short and to the point, yet filled with plenty of real details, this book can show you what works and what doesn't when it comes to using one of today's hottest approaches to successful programming.

Like today's reality TV shows, this title walks you through a real software project in real time. After introducing the reader to the basics of the XP software method (using such shibboleths as paired programming, lightweight documentation, continual refactoring, and the like), the book jumps right in with an actual project built with Java servlets and JDBC. First, the authors disclose their software design for retooling a Web site with login and security features. The scope of this project is necessarily really small, but the win is that the authors go into real detail as to how it is designed and implemented. (While most titles on software engineering hedge on the details, this book gives you the inside scoop on actual design decisions and even problems encountered along the way.)

The authors cover the design process where customer "stories" are partitioned off into deliverables (small ones are called "iterations," which are combined into larger "releases"). The authors give you sample project estimation for how long it will take for each step. They provide the details of the code that does the work for each step, along with sample automated tests. (In XP, code is not "accepted" by clients until it can be verified with tests.) The authors also show off how their initial estimates sometimes went wrong. (Most readers will be struck that almost in all cases, initial estimates for programming time are overestimated by the authors.) However, they do share a significant snag in the process of a typical miscommunication with their client about promised functionality, which is sure to resonate with many readers. By the end of the book, they share their final thoughts on what works and what doesn't in XP, along with some advice for "scaling" XP onto larger projects and teams.

Candid, concise, (and a very interesting read), Extreme Programming in Practice gives valuable insight into today's XP. Whether or not you are evaluating XP for your shop or just want to see what all the fuss is about, this text provides an excellent glimpse into the advantages of XP for creating robust software within budget and on time. --Richard Dragan

Topics covered:

• Quick overview of Extreme Programming (XP)
• The XP process: planning, iterations, and releases
• Developing "stories" with stakeholders
• Case study for a Web application (including logon and security features)
• Prioritizing stories and features
• Team velocity defined
• Iterations and tasks (staffing and planning)
• Writing tests (including using proxies to simulate database activity)
• XP and refactoring
• "Working backwards"
• Infrastructure versus code that works right now
• Communication between customers and developers
• Steering
• Scaling small projects with XP to larger projects
• Sample stories, code, tests, and project-planning documents
• Hints for successful adoption of XP in real projects

From the Inside Flap

This book is a case study describing a Web-based software project developed using a development process known as Extreme Programming (XP). The project is real, driven by the needs of a real customer. The artifacts presented in this book are real. The code is real, the user stories are real, and the anecdotes are real. We videotaped all our meetings and development episodes so that we maintained an honest and objective chronicle of the events. We wanted our readers to have as true-to-life an experience as possible. At first we thought we might have to keep the scope of the project artificially small enough to fit into this book. However, it turned out that the size of the first XP release of the project was both useful to our customer and the ideal size for this book. So even the size of the release is real. Before this project, none of us had used XP in its entirety. So this book also chronicles the adoption of XP by a team that is relatively unfamiliar with it. Our goal in writing this book is to help demonstrate how a real XP project works. We have chosen to do this by example, rather than by explanation. The examples are real. They chronicle the thought processes of the team as it struggles with the concepts of XP. You will see us make mistakes and then correct them. You will see us have insights and then find them to be invalid. You will see the ebb and flow of a real development project. This book is written for developers, managers, customers, and anyone else involved in the development of software. We welcome any feedback and can be reached at the following e-mail addresses:

James Newkirk–jnewkirk@thoughtworks Robert C. Martin–rmartin@objectmentor

0201709376P05102001

See all Editorial Reviews

Product Details

• Paperback: 224 pages
• Publisher: Addison-Wesley Professional; 1st edition (June 5, 2001)
• Language: English
• ISBN-10: 0201709376
• ISBN-13: 978-0201709377
• Product Dimensions: 9.1 x 7.4 x 0.6 inches
• Shipping Weight: 1.1 pounds
• Average Customer Review: 3.1 out of 5 stars  See all reviews (18 customer reviews)
• Amazon Best Sellers Rank: #931,079 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

8 of 8 people found the following review helpful:

3.0 out of 5 stars I expected better, August 22, 2001

By A Customer

Amazon Verified Purchase

This review is from: Extreme Programming in Practice (Paperback)

My biggest disappointment is that the authors did not write automated acceptance tests, which is one of the XP practices that people who are seriously trying to adopt XP have the most questions about. The fact that their development work was sporadic also did not help present the 'normal' usage of XP.

Otherwise it is not a bad book, but I would buy all the other XP books first before buying this one -- particularly "Extreme Programming Installed", "Planning Extreme Programming", and "Extreme Programming Explained".

40 of 53 people found the following review helpful:

2.0 out of 5 stars Don't buy it (my newer review), July 22, 2001

By 

Jake Well (Windsor, Ontario Canada) - See all my reviews

This review is from: Extreme Programming in Practice (Paperback)

I've read 100 pages into the book so far, and I would have to say it is not that amazing. The book basically runs through a project that they did using XP and they share their stories and experiences. The project they talk about is very typical to most websites (a way to register, login, get a forgotten password, etc.)

I was very surprised to see that the project was estimated at 25 days. Even some functions like creating one table was estimated to take 4 hours. It seemed that the developers were not very capable individuals, or perhaps they simply expected an incompetent crowd to be reading the book. There is actual proof of my claim too since even taking their 4 hours to make the table, they had still forgetton to create the 'password' attribute within the table. They realized this when they tested their code. Leaving out those architectural details are we?

I also did not agree with the book's statements in not considering architectural details - in fact none were considered at all, even when it came down to iteration planning. I know this is an element of the XP methodology, but some of their reasons for not doing a model indicated that they didn't understand the problem enough. The only valid reason I found for not planning for future change was that the customer may not request the features required by the more robust architecture. That is valid, but let's think about repeat business. Let's assume they come back in a year's time to make those changes and you'll probably be thanking yourself you did make it scalable. It's less time for you and your staff and less you have to charge your client. Everyone is much happier.

Another instance of terrible design is on page 103. They used an Adapter pattern (found in the GoF book) to adapt a method from their database class to another class with the identical name for the method. Well, as far as I know, that is NOT why you use the Adapter pattern. Adapter is used when you have an API that doesn't follow an interface used throughout the application. Programmer's use the Adapter to make an interface conform to a new one. Well, in using the Adapter in the book's example, they are merely delegating a task, not adapting an unfamiliar interface. Even worse - What was the method called? - findUserByEmail() found inside the Database connection object (connecting and closing the DBMS). Why is it there? No architecture thinking done at all! It should have been placed in a UserFactory or User Data Access Object class in the first place (the book refers to it as its User class). They would have avoided this problem (and misuse of a pattern) altogether.

One more thing about architecture. There was a case where they had made 2 servlets, both containing almost identical code. With XP's refactoring, they had created a base class and inherited appropriately. After restructuring their test cases and refactoring several times, they finally got it right. Wouldn't a solid design have been better? The book states that up-front design is bad. Well, I know the point of XP is to not follow a hardcore design document for the entire project because you realize that customer requirements are voltatile. But, shouldn't we at least come up with a smaller design document for each iteration? I mean, it's not practical for a customer to interrupt an interation - in fact it's a rule the customer cannot do according to this book. I still say, if you are not going to plan your system, at least plan the architecture for a 'subset' of the system - i.e. in each iteration plan.

Even after reviewing the code, I thought some elementary coders were at work. There was a part in the book where they either had to convert some pages from ASP to JSP if they wanted the banner to be the same, but they could have simply encapsulated the banner into a file and included it in both the ASP and JSP versions, saving their estimated implementation time of 5 days.

The book has it's morals, but the project is by far too small to be a true testiment to the success of XP. This kind of project could have easily been done by one competent person sitting at their machine for 2 days, and I do believe it would have been done much better architecturally as well. There is no design pattern work, no architecture and clearly reading their programming flaws and decision making failures, no wonder they estimated a completion date of 25 days.

I gather that XP is still good for projects with much greater complexity than this registration system, but the book does a bad job explaining that. It seems XP is good for programmers that need other support to compensate for their lack of ability to be a good programmer - I know that is not true when it comes to pair programming, but this book isn't doing a good job of convincing me otherwise.

I haven't read any of the other XP books - but stay away from this one unless you want to read bad software designs and coding examples, non-realistic programming errors, and poorly made decisions. It's not XP that would have helped this team, a new set of programmers and architects would have done better.

If you simply want to learn about XP, stay away from this book.

If you want to learn about failures on projects and actually learn something, read the Mythical Man Month.

If you want to spend [price], throw it into lottery tickets, you'll learn about 'wasting money' and how to better spend it.

If you need to learn XP.... try another XP book in the series.

6 of 7 people found the following review helpful:

2.0 out of 5 stars Well below expectations based on the authors' names, August 8, 2001

By 

Sasha Ketko (NZ) - See all my reviews

This review is from: Extreme Programming in Practice (Paperback)

I fully agree with points of Ken Egervary's review - and would like to add a few more points (related to technical as well as other issues) in no particular order of importance:

- while it is OK to use a new terminology to describe old concepts, I don't think it is a good idea to make readers believe that these very concepts are new and unique to XP. I refer to "spikes" and "spoofing" - which are concepts as old as programming itself;

- of course diagrams are easier to understand than code unless the there is very little of very simple code. Should we forget about UML? What about leaving clients a bit more documentation than source code and API docs?;

- concept of refactoring seem to be used only in relation to coding - what about refactoring of analysis and design models (not that there are any in the book)? In fact, there seem to be no analysis and design anywhere in the book - although "backing into the code" concept does sound like a poor-man version of analysis to me;

- arguable concepts such as use of return codes versus exceptions are introduced in by-the-by manner without any argumentation. One could strongly argue that using exceptions for error-handling is a better option because: 1) unlike return code, they cannot be ignored and must be handled or at least consciously ignored; 2) generic error handling and logging mechanisms can be easily implemented especially considering that exceptions - unlike return codes - are automatically propagated and therefore can be handled at different levels as desired; Etc.

- the most appalling mistake of having instance-level variables in the servlets that do NOT implement SingleThreadModel interface (such as, for example, use of private variables request, response, email and url in ForgotPassword servlet). This is NOT thread-safe - and a 5 min "spike" would convince you that this is so. Good thing it was not a project where data more sensitive than somebody's password are mailed to the users who happened to access the same servlet at the same time!

Etc., etc.