Slashdot Mirror


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.

4 of 181 comments (clear)

  1. The last time I saw a select statement ... by jlanng · · Score: 5, Interesting

    When was the last time you saw a select statement on a web page

    Almost every ASP project I've seen has embedded SQL in the presentation pages (.asp files). Yuck.

    .Net goes some way towards alleviating this as the code is usually placed in a paired class (codebehind).

  2. Ignorant Review by TheTomcat · · Score: 4, Interesting

    "("Many programmers put SQL code right on a web page" -- when was the last time you saw a select statement on a web page ?)"

    I think the author was refering to something like this:

    <html>blah blah blah
    <?php
    $sql = "select .... ";
    db_query($sql);
    ?>
    blah blah
    </html>

    and not actually displaying the SQL in the output of the page.. both are bad, but showing the user a query is worse..

    Too bad the reviewer doesn't seem to know enough about the subject to actually catch on to this.

    S

  3. Re:reliability by kryzx · · Score: 4, Interesting

    Your points are good. By designing well you prevent errors now and in the future.

    I guess my issue is that the XP approach does not dictate anything about design. You can and should design well even when doing XP. In fact, in the original book there is a lot of talk about continually reworking the design to simplify and clarify it, and avoiding the temptation to add complexity that is not necessary at the moment, just in case it's needed in the future.

    So, I think of XP as a set of tools, none of which restricts or prevents good design.

    It would be interesting to collect stats on projects are compare reliability produced by different design methologies, platforms, languages, tools, etc., looking for correlations, but XP is just one piece, and does not equate to a design methodology.

    --
    "I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve."
  4. Re:reliability by William+Tanksley · · Score: 4, Interesting

    Somehow, I would never trust an "extreme programmed" program.

    Would you ever trust any other program in this sense? Just curious.

    I feel (perhaps just a prejudice) that

    Sounds that way. Unless you have some facts that you haven't shared with us...

    extreme programming is a "do now, think later" kind of approach.

    No, it's the other way around -- "think now, do now." You're supposed to do things as you think of them -- when you come up with a clever design, don't write it down and walk away; instead, codify it as a test and then implement it. All the practices of XP are supposed to come together to prevent premature or delayed action: pair programming ensures that every idea put into code is understood enough to be explained to your peer; TDD ensures that every change made to code actually _adds_ some functionality; and so on.

    I'd be interested in knowing if there have been studies with respect to reliability of extreme programmed projects.

    A very interesting question! I think that we'll have answers on that in about five years. XP as a movement is a little new; very few companies have had a chance to adopt it, and only a few formal projects have been run with it.

    Until then, any XP shop wishing to perform a high-reliability-required task would be wise to adopt some of the known reliabilty practices -- formal reviews, for example.

    -Billy