Extreme Programming for Web Projects

PinglePongle writes with this review of Addison Wesley's Extreme Programming for Web Projects, writing "The authors work for a web shop, building websites for customers, and try to use their experience to make life easier for their readers. Their main point concerns how traditional web projects are structured to leave at least one of the parties taking a big risk on the project: if the project is 'fixed price, fixed scope' the developers take all the risk, if it's 'time & materials' the customer takes a risk -- they can not be sure their money will lead to whatever it is they want." Read on to see whether the authors have successfully outlined a fairer, more successful system in the rest of PinglePongle's review, below. Extreme Programming for Web Projects author Doug Wallace, Isobell Raggett, Joel Aufgang pages 165 publisher Addison Wesley rating Poor reviewer PinglePongle ISBN 0201794276 summary A book about applying the Extreme Programming methodology to web projects.

Can good ideas dominate the buzzwords? This risk -- the authors contend -- is the reason many web development projects fail in one way or another. The client's objective is to obtain maximum value, the developer's to incur the least cost possible without getting sued.

The authors show a way in which this risk can be shared fairly between the client and the developer, by using XP and iterative development cycles, alongside a release plan, to acknowledge the risks inherent in a development project, and manage them rather than try to pretend they don't exist. The project team -- client and developer -- work together to create an iteration plan, and use this shared understanding of the requirements to guide the project.

The book is structured into 4 parts: Part 1: XP and Web Projects explores the problems associated with web development projects. Part 2, Working on Web XP Projects explores some of the practicalities of the authors' process - iterative development cycles, the development environment, team roles, and the graphic design process. Part 3: XML and Web XP is a bit of an oddity in a methodology book -- it focuses on some technology-specific issues which the authors claim can be addressed by using XML. Part 4: Web XP Best Practices discusses planning, design, coding and testing issues.

What's good about this book? Well, there are some insights into the relationship between suppliers and customers in development projects. (I don't believe, though, that they're as specific to web projects as the authors seem to claim).

What's bad about this book? It seems to be a sales brochure for the author's web shop -- "we do things thusly, and it yields fantastic results every time." The text is full of fairly broad, even sweeping statements ("Many programmers put SQL code right on a web page" -- when was the last time you saw a select statement on a web page ?).

The authors do not really seem to be able to identify those aspects which make web development projects different from other types of development. Some of the team roles they recommend are bizarre -- the authors identify the role of "Strategist" who seems to help those poor idiot customers to understand their own business. This may be necessary on some projects, but I find this attitude very condescending -- the days when web development was portrayed as a cross between alchemy and spiritual enlightenment are long gone. Many of the sections are very superficial, but the book is littered with footnotes saying "Chapter X discusses this in detail."

In short, I'd say this book is too lightweight for people who understand XP already and want to learn how it applies to web projects, and novices are likely to get hung up on the largely redundant side tracks (CVS versus MS Sourcesafe -- Huh? How did that get past the editors?) to be able to see the extreme wood for the trees.

You can purchase Extreme Programming for Web Projectsfrom bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

How much XP is there in the real world?

[kryzx]

I've had this in the back of my mind to submit as an "Ask Slashdot", but this is as good a place as any for it.

XP was all the rage for a little while there. There was talk of it everywhere, especially here. I read about it some and became very interested in it. I think many of the core ideas are valid, and it seems like it would be a fun way to develop.

Now that the hype has died down, my question is this: How many people out there are really doing XP? How much has this really caught on? Is it just a bunch of talk?

If you are actually doing XP, tell me a little about:
* the industry you are in
* the kind of project
* how it was done before
* what prompted you to make the switch to XP
* how that switch work and how long it took
* and how things have been since moving to XP
* do you know others doing XP, if so how many

Thanks for sharing your experience.

Not a bad book

[null etc.]

I've read this book recently, and must disagree with the reviewer's assessments.

Although I'm not a fan of extreme programming (it seems counter-intuitive to my highly structured mind), the aspects mentioned by this book have accurately reflected the last five years of experience I've had as lead architect and developer at a custom development firm.

Let me give an example. The reviewer condescends the book for assuming a "Strategist" role is necessary in a successful project, since the customer undoubtedly knows his or her own business.

In my experience, which may not be the gospel truth, but is valuable nonetheless, the customers often do not know their own business. The individuals of an organization sometimes know nothing more than the rote daily routine with which they've been guided over the years. Ask them an insightful question about why or how a process came to exist, and they might give contradictory or vague answers. It is the role of the strategist to exhume the truths and necessities of an organization, which are not always superficial or easily understood.

The reviewer also disbelieves that SQL code is ever embedded within web pages. Many quick and dirty (or under-engineered) web sites do use some form of embedded SQL, however. I'm often called in to clean up such sites, and make them more secure and modular.

The book is admittedly light on related topics, and perhaps a more academic treatment of extreme programming would have been more useful. And I do agree with the reviewer in that many statements within the book seem like advertisements for the author's own company.

Nonetheless, Extreme Programming is a practice understood by few (comparitively speaking), and this book serves as a good bridge between Extreme Programming and more structured development methodologies.