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.
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.
I think the author mean in php/asp/other embedded languages pages, where finding plain sql code (instead of calling a library that hides for portability the sql code) is very common yet.
Of course, that don't display in the visitor browser, at least, not unless is intended (.phps) o "accidental" (the old ::$DATA that showed the .asp code), or is part of the debugging process (visible or in the html generated code)
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 ?
When is the last time you worked on a production system? Every ASP, JSP or PHP app I know has them. Eventhough lots of people talk about MVC and Model 2 stuff, very few people actually implement solutions that way: it takes more planning, the code/build/test cycle is longer, etc. People cut corners, it's a fact of life.
there's no place like ~
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.
I agree with your assesment of needing a "Strategist" role. That is the role I take whenever someone comes to me with a new project. They may know their own business, but rarely understand automating it. They have a "process" hat mainly involves doing whatever seems right for that case- something very tricky to code. Or they want to collect data and generate reports that they don't have any real plan to use.
Or even worse, they expect that just putting their processes online will magically solve all their problems. So a "Strategist" is definately needed to help set goals and expectations.
Ummm...bullshit. I have never seen "upper management" give a shit about the education levels of their ranks. Indeed, apart from young graduates it is something that has absolutely no bearing for virtually all of industry. The idea that upper management is filtering through CVs to find someone with insufficient education is ridiculous, especially in technology fields. If you saw someone fired for not having a degree, realize that it was a red herring to fire someone they wanted to fire, and the degree issue is a non-starter.
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.
This is a rather short-sighted view. In 1997, I was faced with the same choice: Experience, or degree. I chose both. Finished high school at the end of 1997, started doing a Bachelor's degree in Information Technology part time, in 1998, looked for work, had a few odd jobs but nothing major, and in my 2nd year, 1999, started an e-billing company with 2 partners. Finished my degree with honours in 2001, and also had a moderately successful company. (Moderately successful back then, substantially more successful now). Good luck to you with your degree only, though.
Admittedly, it has a lot to do with luck, but I'm pretty sure that most people doing their degrees right now could improve their situation significantly, instead of getting their degree and then wondering if it's going to be all that useful in the ultra-dynamic I.T marketplace.
My hiring policy is simple: if you have a degree, great, if not, also fine. It all boils down to how you do in the technical test that my colleagues and I have devised. It's based on knowledge of the following subjects: Operating systems, Python programming, C programming, Zope usage, and Network knowledge. It doesn't matter how many degrees you have, if you want to be a programmer with us, you need to do well in this test. Most of the degreed applicants' CV's look something like this:
Look, degrees are impressive and all, but most of the CV's that have them also contain large amounts Microsoft, and that's not acceptable in firms that use non-Microsoft technology for scalability and stability reasons (our custom e-billing app needs to serve millions of requests per day and send large amounts of mail without crashing, freezing, BSODing, or whatever the case may be).
As for other organizations, from all I've heard and experienced, people with degrees are more likely to get laid off because they tend to cost more than non-degreed people, and in business, it's often the bottom line that counts, unfortunately.
From a skills perspective, people who have been programming since their teens or earlier tend to be the best technically (I was one of these people), and degrees do indeed help to sharpen and augment those skills, but are by no means the end-all and be all of programming, experience is far more important.
Hope this helps, and I hope that you manage to find a job.
Successful software development has always been about people - not development philosophies, and not about which language you use. If you're working with people who are winners, you're going to find a way to succeed.
That said, I'm sure there are many who feel very strongly about operating systems, development environments, programming languages, etc. (myself included), but none of it matters if you don't have the right talent in place.
Just my master-of-the-obvious aside ...
I've found test driven development very useful on my most recent project, and intend to practise it in future too.
On this occasion, I did what you suggest: I built unit tests during development and threw them away when they were costing more time to maintain than they were saving in bugs that would not have been found another way. Once it was possible, I developed tests from the user's API level (its a middleware product), and these will be maintained for the life of the project. These API level tests include regression tests for specific bugs.
The XP folks seem to suggest maitaining unit tests at a level I consider excessive. I think they suggest one test per non-trivial method on all classes. This just seems too much, and very hard to achieve, since even in the best designed projects, individual methods are hard to test without also testing a bunch of other stuff.
It sounds like your project was suffering mainly from a lack of design skills. Spending a lot of time maintaining tests implies too much coupling between components: the only way that can come about is if changing one component affects many others, so there tests need updating too.
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.
... (I suffer from this occasionally). Then they may not have the best people skills to break this to the client easily, and things get testy. YMMV, but I've found this to be true slightly more often than not.
Not only do customers often not know their own business (or at least haven't thought about it in any systematic way), they generally have no idea of a) what's possible, and b) what's cheap, and c) what's good on the web. They get really caught up in features.
I groan when I'm in a requirements meeting and I hear a client start, "Now, can there be a 'button' that..." Generally they get this image of a button and various form elements in their head, and don't really have the training to think it through, or even better, step back and think about what they're trying to do and what kinds of services can fit them--let the details work themselves out later.
Clients who have this kind of blinder focus on details tend to have more unrealistic expectations and greater disappointment when the magical mind-reading system doesn't appear. They are very frustrated with the process of fixing this system in development.
This isn't their fault. If this were easy, everybody would do...oh wait, everybody would do it well. They don't know that the system requires mind reading--they just assume several steps in between.
Your average developer, head deep in code, doesn't have the business process experience to chain the processes together and see the problem until they get into the code and realize somebody forgot Phase Two:
Those who are really good, and they are rare, at Internet strategy tend to have experience in organizations (not necessarily businesses) and technology. Too little technology and they plunge off the cliff with the client (we have one of those in our company). This is why domain experts with tech experience are as valuable on Web projects as they are on traditional client-server projects.