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.
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.
Is there a good book out there on this exact topic? I enjoyed 'Clouds to Code' and 'Design Patterns' and was hoping that there was a another book that delved into designing singular web projects ( with availability later on to pick off the shelf and change simply for new customer ) as well as integrating XML and SQL services.
Does anyone know of any good suggestions?
"("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
So let me guess...
You are one of the many who have never read more than two sentences about XP, and jump to the conclusion that because eXtreme is in the name it must be hacking.
I think your assumptions are the exact opposite of what is actually true; "extreme programmed" programs should be more reliable, because they don't guess for tomorrow. If XP is done right, what you have is what you need...nothing more. This is the essence of KISS. If you can't make it reliable by doing the simplest thing possible that solves the problem, I shudder to think what you will produce if you are guessing for tomorrow and adding things you don't need.
There are plenty of studies... just google for them.
Scott
a presentation layer, eg jsp over a presentation package, eg tags
and
a business logic layer, eg java classes over a data abstraction layer, eg bc4j
If you do this, you get re-usable, maintainable code. If not, and you're building anything bigger than a pretty noddy app, you're not going to be able to do anything with it six months after the initial build.
Hell, I've even built noddy apps badly and had a hard time maintaining them six months later.
Incidentally, wtf is extreme programming? Somebody?
You're only jealous cos the little penguins are talking to me.
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."
I guess my issue is that the XP approach does not dictate anything about design.
Actually, it explicitly does. One of its practices is Testy Driven Design: every element of the programmer's design is expressed in the form of a test, written in automatically executable form before anything is added to the code.
Another rule XP requests is to minimise Big Design Up Front: don't do design on something else else until you've proven the design for what you just did. In other words, don't design something and then leave it unimplemented; let every implementation be completed as close to its design time as possible.
I don't use XP, since my company has its own methodology (CMM level 3); I do use Test Driven Design. It works extremely well, and has the pleasant side effect of producing tests to hand in with my code for no additional effort. Given what I've experienced with TDD, I would take up XP in a heartbeat.
So, I think of XP as a set of tools, none of which restricts or prevents good design.
XP is not a set of tools, although there are one or two practices in XP which make sense outside of XP (for example, pair programming can be imagined in another context, and TDD works very well without XP). Rather, it's a complete methodology, much like the Spiral methodology or the much-feared Waterfall (and no, waterfall isn't a myth; I've seen it used a couple of times, and most of the rest of the time it's a good approximation).
-Billy
-----
Free P2P Backup, Windows & Linux
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
In our current project, we've achieved a reliability improvement of almost 2 orders of magnitude based on our XP methodology, and it's increasing every day.
.01%)
It's actually difficult to track because the original project didn't monitor error rates particularly well. We do know that they had more than 1000 errors over 14000 "processing cycles" (a defined chunk of work.) Our current system has had 7 errors over 7000 "processing cycles".
The vast majority of these improvements come from Pair Programming and Test-Driven Development.
And - of course - we now have tests for those 7 errors!!!
(For those who care, a "processing cycle" has about 10 feature-points that are executed - so the original error rates are somewhere around 1% (pretty dang high) and ours is around
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
An online auction company I recently worked for has a massive hang up about MBAs. If you want to do anything technology related that's not actually coding, for example Project Manager, then you'd better get yourself an MBA.
Also during recent reading of job advertisements I've seen a lot of ads that say something like "must have good degree from a red brick university."
Brought to you by the author of such childrens' classics as "Some Kittens can Fly!" and "All Dogs go to Hell."
While I do know the difference between the presentation layer, business logic, and data storage - what if the customer doesn't actually know the full requirements of the site (or indeed a specific section of the site) prior to them wanting it to go live?
I personally love working on projects where the presentation logic is separated from business logic, but unfortunately the majority of my customers need it in production yesterday, and have no time themselves to actually go through the requirements, nor are willing to commit to requirements that will no doubt change in 3 months time.
And for them, I believe, its just a matter of being in the business they are in - their core business has practically nothing to do with I.T. (short of perhaps the checkout scanners at the front of each of their stores). Its only that they are a nation-wide company, and therefore have an image to uphold.
I feel your pain - I really do. We deal with those types of customers every day and it's enough to drive me to drink...it usually does. But I think you'll find that you'll be saving time in the long run by adopting some of these principles in every project.
The Jr. members of my team don't understand how I can make major changes to some of my programs in hours when it takes them days to make simple changes. Well - it's all about the rewrite. I don't find myself rewriting my code as much as I used to...it was like the day I learned that by writing object oriented code, I didn't need to completely reinvent processes to make modifications...just add new methods or - in cases where requirements change - new methods+properties.
And - what I always tell my coworkers - if they needed it yesterday, it's already late. Take 2 hours and come up with a good plan...