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.

Re:How much XP is there in the real world?

[kryzx]

Thanks for the lead.

With the help of Google I found the article here:

http://www.informationweek.com/story/IWK20020111S0 046

Re:How much XP is there in the real world?

[orenmnero]

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.

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.

Re:XP is a manager's dream

[dismayed]

You need more computers overall, because you have development machines, then usually your own "personal area" where you can handle email and manage your personal life... unless I misread Planning XP. :(

Re:Optional Scope is a non-starter

[Anonymous Coward]

Saying something like "let's get broad agreement on the general nature of the site and then work in iterations to refine the details. Now please sign this contract for three months of work for four developers" just didn't work.

We use a process inside fixed price/term contracts in which we kick off the project by refining the core scope/requirements with the customer. These are the higher level functional tests we must meet. These drive the initial High Level Design which is the kick off document.

We then go into the process development identifying components that need to be written, lower level business processes that we must meet to match the functional tests etc. We run through that small cycle which is punctuated with a customer acceptance test on that component. Before the customer acceptance test, the High Level Design is modified to incorporate the design changes. At the end of this cycle we also produce an As Built document. Basically we use the code to drive the documentation. This is necessary for many government jobs in which the documentation component gets as much money as the code development phases.

At the end of the customer acceptance test for the cycle we revise the requirements with the customer and go off on another short cycle (sprint in scrum). Each cycle drives the HLD and As Builts to their final customer form where it is the code development that is driving that process. Works pretty well for fixed price contracts where the phases include documentation as deliverables.

omico--

RUBBISH !!!!!

[Anonymous Coward]

"Extreme" Programming must be one of the most idiotic buzz words to ever come out of the software industry. And considering that the industry has a pretty strong track record on idiotic buzz words, the competition is pretty tough in this respect.

Basically, "Extreme" (God - it makes me cringe just to type it!) programming means "doing it right" ! ie - writing a bit of code that (a) works, (b) ...err ...works ? and (c) ...oh dear ...works !

ie - it's meaningless bollox.

Extreme Programming brings teamwork to the cubicle

[rpiquepa]

As I wrote in this column, extreme programming is not really new. "Extreme Programming (XP)" is just another way of saying "Team -- or pair --programming". Programming in pairs is the most difficult aspect for many to accept (believe me). Even for XP die-hards like Edward Hiett, who works for San Francisco-based Evant, programming with someone looking over your shoulder remains disconcerting. ``Programming is a very creative process and requires a lot of concentration. It's natural to want to go away and do it by yourself,'' says Hiett, , where all programmers work in pairs. ``With pairing, you have to give up control.''

may I never have to maintain your code

[Anonymous Coward]

A seperation of business logic from presentation allows for more maintainable code and a reduction in lines of code. In most applications I've seen, you use a lot of the same SQL statements over and over, then have the ones that are specific to the page or problem your working on. If you change the schema, then you must search through all pages on the site and fix the SQL(annonomous or call to stored procedure) on each and every page. Not only is it time consuming, but you're also prone to miss some. If you abstract the business logic and domain out, these changes are much simplier and faster to do for the same SQL call is in one place and that's the only place you need to change it. Ideally, the presentation layer will talk with a business layer who talks with a domain layer. The business layer just returns what's neccesary to rendure a page or screen. The business logic could also be interfaced by tag librarys that allow the html developer to focus on presentation logic and an engineer will code the business logic plus the calls those objects make to the domain. I recommend you get read some books on patterns and the gang of four books. It'll help move you from the realm of hack script kiddie to engineer. So in summary, the idea of seperation is for isolation and reuse of common functionality.