Slashdot Mirror
Extreme Programming for 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.
for Laid Off WebMasters Who Dropped Out of College With a Passing Knowledge of Front Page to Work For a Dotcom, but then I've always valued a four year degree.
This books sounds like buzzword fluff.
A. Rightmann
is writing code while skiing 20 yards ahead of an avalance AND compiling on first try.
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
Somehow, I would never trust an "extreme programmed" program. I feel (perhaps just a prejudice) that extreme programming is a "do now, think later" kind of approach. I'd be interested in knowing if there have been studies with respect to reliability of extreme programmed projects.
The law of excluded middle : Either I'm foo or I'm foobar
Sounds like it hasn't got much actual XP in it.
Surely not another book with a buzzword in the title that doesn't actually focus on the alledged subject at hand?!
when was the last time you saw a select statement on a web page ?
About 10 seconds ago on my current project. I fail to see why I should make a seperate file and include it for one SQL statement, or even for the 20 or so I use...
Can anyone explain the logic behind this? If they mean "when was the last time you saw SQL directly put in the html", then the answer would be never apart from the mysql manual...but then surely thats obvious...if they mean "when was the last time you saw SQL in a page-generating script", then I don't get the problem.
When was the last time you saw a select statement on a web page
.Net goes some way towards alleviating this as the code is usually placed in a paired class (codebehind).
Almost every ASP project I've seen has embedded SQL in the presentation pages (.asp files). Yuck.
Allah Invests!
Ignorance is not linguistic drift.
How else can you do a major cost cutting exercise (only buying half the PC's you actually need) and at the same time con your geeks into believing that you are following the leading edge of software dev ?
Anyone else notice the incredible range of books with titles of the form X for Y recently? Extreme Programming for Web Projects. Lifecycle Management for Java. Python for Information Engineers. Buzzword Awareness for Techies. Cluefulness for Suits. There seems to be no end to this trend ...
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
"("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
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.
"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."
I just visited the authors' web site at Agile.net. I think it tells us everything we need to know about this book. The home page looks as if it has been through a shredder. Fortunately I have a better back button.
Modest doubt is called the beacon of the wise. - William Shakespeare
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.
Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.
There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.
Oh goody, another XP flame war on /. I might as well jump in the fire.
Well, I worked at a web shop for a few years (though, that was during the bubble, maybe things have changed now) and I looked into using XP because many aspects of it seemed to fit our needs. But one aspect always hung me up and that was that XP projects are basically optional scope contracts.
Basically, the clients always wanted to see the whole site (at least mockups) before they would sign off on the work. Even if we all knew that there was likely to be significant changes along the way.
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.
Now, XP proponents will claim that this can be overcome by educating the client. I'll just say that that wasn't my experience. Optional scope contracts just wouldn't fly. Other XP proponents might say to hide the process from the client and make an XP project look, to the outside, like a waterfall with very flexible change management, but I wasn't happy with that sort of methodological dishonesty.
I think that this problem with optional scope is a problem not just with web sites but with any project where contractor and client are different companies. Most of the XP success stories I've heard are on projects where the client is an internal division of the same company, so things are a little less confrontational and more flexible.
-----
Free P2P Backup, Windows & Linux
...because it's the only way to finish the Website before the .com-Startup goes bancrupt.
This is not a joke.
I've seen plenty of this and I believe it's nearly always true. And I think the reviewer is correct in stating that this is not unique to web projects.
So, with that in mind, I'll assert that it would be overall _more efficient_ (less waste of money and resources) if both parties were able to manage uncertainty and risk in projects in a less adversarial manner.
Call me on that assertion if you want, but risk management is an important part of managing the software development process for just that reason. So, why _not_ come up with a better way to manage risk across organizations??
I don't think contracts are bad things (just the opposite) and I don't have The Answer...but I'm imagining a better contractural toolkit and a better set of development and project methodologies that allow some uncertainty and flexibility and assigns risk at a more granular level than 100%-0% or vice versa...
For an analogy that's pretty far afield, I saw a report recently that said something like 50% of mergers and acquisitions fail to add value, but if the M&A was contested or if there were multiple bidders, it goes up to 70-80%. Demonstrating, I think, that while people enter into contracts freely, those entities or contracts that are more adversarial are more wasteful of resources
OK, let's all get out there and fix the consulting business so it's more fun to work on projects for clients...:^) Comments??
Faster, better, cheaper; pick any two.
I am involved in a multi-year cleanup of a system that originated with an XP approach, and test-first design.
To start with, let me say that the XP approach utterly failed in this case, but it was probably in good part to the people we were working with still learning Java at the time and also having terrible design skills (or rather I should possibly say, design experience in other languages but not in Java which led to ill-fitting design). So, they probably would have generated drek no matter what approach they used.
However, as I was around from the start of this project I was able to make some interesting observations. The first is that you are correct, if you build code that passes all tests but still does not do what you want, then your requirements used to build the test are wrong. However, I've always been confused by this aspect as I thougt a requirement-poor environment was supposed to be where XP was helpful...
The larger issue I have noticed through my own experience as well as this project was that test-first is too simplistic a strategy. Instead I would break testing into two sorts - "scaffolding" and "regression".
The original project did not break up tests in this manner. As a result, the core of the project became encrusted in tests. After a while more work was being done on tests than on the actual project... at which point the buisness owner for the project raised hell, and testing was dropped altogether. Obviously that was a bit too far, but it did get the project moving, and ended in a state where it worked (though I still have a terrible mess to clean up and a very fragile system).
Back to the breaking out of tests... I think they would have been much better served by "scaffolding" tests that are created during construction of a system, but ultimatley are thrown away when the system works well so you do not have the overhead of maintaining tests while adding to your system. Then of course there would be true "regression" tests that managed to cover most of the application testing, and ensure large portions still worked after changess... but they would be few enough in number that enhancements of fixes would not mean more work fixing tests than code.
I've used a scaffolding approach in my own work and designs, and find it woorks really well. It gives you enough tests to get much of the touted test-first benefits, but does not leave you with a system that cannot be changed for fear of cascade fixes on multiple, ancient, tests.
I would be interested to hear what criteria other people use to abandon a test when doing test-first programming.
"There is more worth loving than we have strength to love." - Brian Jay Stanley