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)
What do you know-of that is effective in knowing and communicating what this book purports to be?
Messages to/for me ( in me journal )
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.
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?
Allah Invests!
Ignorance is not linguistic drift.
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 ?
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.
are likely to get hung up on the largely redundant side tracks
so, then, the final review for this book is -1, redundant???
xao
xao
http://TheHillforum.hopto.org
"("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."
Well, I guess the author meant PHP's SQL statements' embedding...
Trolling using another account since 2005.
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.
and that's why he never has to use his backups!
traditional web projects are structured to leave at least one of the parties taking a big risk ... see whether the authors have successfully outlined a fairer, more successful system
I don't understand what is unfair about the supposed existing system. One of two parties, both of whom willingly enter into a contract, supposedly exposes itself to more risk: so what ? If the company is smart, it takes on that extra risk in the hopes that it will be able to realize a larger reward.
The point is that both parties enter into the contract willingly and freely. So what can be unfair about that ?
www.cgisecurity.com/lib
Java security papers
XML Security
A traditional web project? Has the web been around that long!?
This book seems to assume that customers
a) Know what they want
b) Are capable of helping to formulate a realistic iterative dev plan
In my experience, customers tend to want fixed price projects because they know how much they'll pay up front, but then they also want changes made at a whim if they don't like something, they often expect the developers to be able to read their minds regarding ill defined requirements and they expect it all to be defined, developed and delivered yesterday.
The key to successful fixed price development is to make sure that the client understands their own requirements and understands that anything outside of that understanding is a Change Request for which they will pay over and above the originally decided project cost.
Regarding Extreme Programming - one cornerstone of XP seems to be two developers working at one machine developing one Unit together. You'd have a hard time trying to convice someone managing a fixed price project to sign up to this as instantly, your costs for each unit double (managers can't see time savings).
I think that if a customer can be persuaded to go Time and Materials and a realistic agreement can be made re: milestones between the developer and the customer, then you have the best of all worlds.
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.
the authors identify the role of "Strategist" who seems to help those poor idiot customers to understand their own business.
We feel it's only fair to also have the customer appoint one of their own people we like to call the "hygienist."
They help the poor idiot programmers understand the daily value of brushing the back of your tongue, that wax paper from discarded pizza boxes is not a replacement for clean underwear, and keeps our dew-induced flop sweat upwind of the secretarial staff at all times. They often do breakdown and get the recommended VPN installed to lessen the direct contamination from our biohazards.
Go ahead. Do it. What sort of answers are you going to get?
"I'm a web developer," or "I'm a Java programer."
People who answer that question in that manner will generally buy these books, in fact, insist on them. It never occurs to someone who thinks of himself as "a suit" that there is such a thing as *cluefulness,* detached from what he "does."
Publishing a book on cluefulness would smack of "theory" to these people, and theory, to these people, means not practically useful.
Cluefulness for Suits for Dummies, however, the suit can recognize as describing himself to a tee ( although the irony of the accuracy of that description often eludes him). It smacks of being useful, to *him*, without all that extraneous stuff about cluefulness in general.
I mean, really, who would want to waste their valuable time just being clueful, in general?
KFG
radio waves
-----
Free P2P Backup, Windows & Linux
when asked what I do, I say "computer stuff". Otherwise, it's a long string of shite with too many commas and the person asking stops listening before I finish. I used to say "web developer" but less than half of my income is made from www projects these days. "Net developer" would be more correct but then I would have to explain it.
The truth doesn't care what I think.
...because it's the only way to finish the Website before the .com-Startup goes bancrupt.
This is not a joke.
I wish the reviewer would discuss what exactly the books asserts will help the developers share risk with the client. Extreme programming may be a great way to tackle these projects, but it doesn't do anything in and of itself to share risk. The only real way to minimize risk is for both parties to have a mutual understanding of the development process regardless of what that may be. XP will at best only be truly understood by the developer; the client will not likely know what the proper test cases are. So whether you use XP or not, the success of the contract will depend on the ability of the developers to explain what the client needs to know at each step of development and be forthcoming about the reality of development. Problems commonly occur because both parties are unwilling or unable to put themselves in each others shoes. Whether we like it or not developers are the ones in the position to do this since understanding a marketing plan is a lot easier than understanding how software development works.
to hang out with who, when they ask you a personal question, are actually interested in the answer.
If find it very a very effective tool to weed out those that I'm not interested in talking to myself to simply answer the question as asked, instead of iterpreting it as "what's your job?", which is, in most instances, none of their business anyway.
Anyone who wants to talk to me about physics, bicycle racing, trout fishing, folk music Donald Westlake novels or subsitence farming, well, I'll stand the first round.
If someone asks me what I do, and their eyes glaze over when I start talking about R/C car racing, well, they're going to be a bore to talk to anyway.
KFG
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.
dedication?
you didn't even finish your school work. what kind of example of dedication is that?
When the going gets tough, make up an excuse and bail.
"get used to it" is right.
"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.
...err ...works ? and (c) ...oh dear ...works !
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)
ie - it's meaningless bollox.
The best thing about XP is that it has gotten a heck of a lot of people to think about and even get excited about software development processes.
That is no small accomplishment.
Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge
.. I don't know too much about it, but it does really appear to be a poor mans DSDM. Paired up coders, the client sitting in the office every day... these seem like blunt edged approaches to solving the problems of dynamic, rapid, development. DSDM provides a far better approach, of defining requirements and envolving the client during an iterative development cycle, without what seems to be a cost overhead in XP DSDM allows you to ensure that your client gets a product fit for business, and that it does not go over budget/time. Regardless of differences here, the above book sounds absolutely dire!
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
Isn't always the 'better' way, but the basic concept is to use an additional layer of abstraction.
Basically, rather than call 'select field1 from table1 where field2=value2' you call some sort of function. That function contains the information needed to get the information out of the database.
This way, if you ever need to change your backend, you don't have to go picking through every web page on the system to see where that data object might have been referenced.
Now, for one-off projects, this is a cumbersome annoyance, which only gets in the way of the end product. If you're putting something online for a week, and it's going to then go away, this probably isn't worth it. If it's going to stay around for years, and you may have to make changes to your data model or add some wierd functionality later, it's better to have the abstraction, as it keeps you from having to essentially rewrite everything.
In some cases, the extra level of abstraction may save you processing time, as well. Oracle will have to maintain multiple execution plans if there's even a difference in capitalization of field names [even though they're not case sensitive], but by making sure that everone calls the same function, which calls the same exact SQL query, you avoid this problem.
This also makes it much, much easier to optimize your code, oracle or otherwise, as there are times when just the order of the items in the query will affect the execution time. (as it may affect how it does joins, etc).
Now, in your case, you have one layer of abstraction, to keep you from retyping the exact query each time, you may still want to have seperate functions that get a specific set of information, so that you can optimize or otherwise modify them as needed.
Build it, and they will come^Hplain.
I don't really care to hang out with geeks, for the most part. I don't really like most of them. My eyes glaze over before I even finish hear the words "R/C car ..." or anything else to do with video games or sports.
The truth doesn't care what I think.
What you, americans, call XP, i call it: intelligent programming.
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 ...
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.''
Should I be pleased or insulted ??
My first ever 5-mod - but it was modded Insightful - when IT WAS SUPPOSED TO BE **FUNNY**
Bah - back to comedy school for me.
Enough has been said about the SQL comment--suffice it to say the 1st lesson in "Web Application Development 101" should be "Develop 3 layers: Data Acccess, Business Logic and Presentation". I think most web developers missed the 1st day of class. Not only is there too much SQL and related data access code embedded in ASP, PHP, etc--there is often a great reliance on embedding business logic (and yes, some presentation elements such as UCASE, padding, etc) into non-portable SQL statements and stored procedures. In simple situations (if you can GUARANTEE your small project will stay small, which is very rare) mashing everything together makes for faster development and more compact code. In the 99% of other cases you'll eventually end up with a big bowl of spaghetti. Perhaps it's because many web programmers are trained on syntax (the mehanics of Java, Perl, PHP, HTML and so on) and not on design.
As for assigning a "strategist"--that can be invaluable to a project. The end customer in most cases knows his business as it presently runs, and most often they are not a tech business. I have clients in manufacturing, distribution and food processing/agribusiness. Their business is knowing how to make wigits or food or chemicals or how to send stuff all over the continent--and all they want out of computers are ways to make these tasks work better--and more often than not they must rely on "strategists" to show them HOW and WHAT computers can do to achieve that. That's the case for ANY component of a client's business that is ancilliary to their primary goals.
I don't always use a strategist--but I will if the job is big enough and/or to establish a relationship with a new client. In my opinion (and experience), a good "strategist" should be the following:
1. The strategist should NOT be a past or present employee or long-standing affiliate of the client--that might seem counter-intuitive however someone with intimate knowledge of some or all of the processes in a business standa a chance of being blind to change. Viewing "from the outside in" is most often the best way to spot and change counter-productive practices.
2. If possible, a person with industry knowledge (if you're going a web project for Pepsi, then someone who knows the soft drink industry). This can be more important than having an advisor or strategist that knows technology...which brings us to:
3. The strategist should most certainly NOT be a programmer on the project (or indeed be involved in project development AT ALL beyond the requirements phase--or in XP, I suppose developing the tests). If there are questions about feasibility or time/resource requirements to achieve functionality, it is not the strategist's job to answer them--the answers should be provided as feedback from the developers upon receiving the specs/tests. Not only can programming be an iterative process--so can (and often should be) determining project specs. The last thing a client wants is to get mired in an alphabet soup discussion of SQL, ASP, PHP, etc. on what is required to satisfy a reporting requirement--all they want is to state a list of wants/needs--then they want you to think about it a bit and tell them how long and how much $ for them so they can prioritise. Having a non-programmer strategist as a go-between helps immensely in avoiding that trap.
We all seem to forget that SQL was supposed to be the data abstraction layer. Somehow it's now this ugly stuff that no one is supposed to touch, and every project that is built attempts to reconstruct a data abstraction layer.
Not to mention that OO abstraction on top of a relational model causes significant complications. How does one perform true joins? By building additional classes that represent the "join" of two other classes? What about complex reporting queries?
Of all the apps that are claimed as "maintainable" because of OO abstraction, I've never seen one that actually accomplishes this in a truly clean way. Because it's hardly ever possible if you're making true use of a relational database.
... but Moses scores on the rebound!
I must agree on your comment about a Strategist. Whether you follow XP or not, you need this. A client might well know their business inside and out, but it's unlikely they know that much about the internet (or they probably wouldn't need the likes of us), or how this tool relates to it. And we've had plent of clients where even key people in the company hadn't really given much thought to certain critical business issues. A good part of our job is discovering and exploring this.
It's a lot of work, but a good strategist will keep you sane.
This is the voice of World Control. I bring you Peace.
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 point is the sweeping statements that litter this book, often implying that Web XP (which after reading this book was still a pretty hazy concept to me) is the only solution. The quote in question is from a section about the team roles in Web XP projects - it is almost left dangling on its own - there's no discussion about the problem, and none about possible solutions.
Have I seen a lot of embedded SQL in my time ? Sure - I've even written some. Is Web XP the only cure for this evil ? Uh...no. In fact, does any process shield you from poor design or poor implementation ? Well, no, probably not.
Another quote that annoyed me : while talking about the quality of web site code, "Few developers used an object oriented approach to development. Most used procedural languages, which made refactoring code or making changes to it much more difficult". Well, I'm a bit of an object bigot, but I would contend that the key tension here is not OO versus procedural, but rather time versus quality. I've worked on code in procedural languages that was very easy to work with, and OO systems which were an unholy mess. The reason many web sites are brittle is not that they don't use the right inheritance tree, but rather that they are put together in a very short space of time, and with ever-changing requirements.
It's all very well in practice, but it will never work in theory.
That's not what I thought was annoying - it was the very condescending tone this book takes towards the business folk.
At best, this is consultant mumbo jumbo - "just you leave all the difficult stuff to me, I have a brain the size of a planet and will prove it by saying the word "synergistic" a lot".
At worst, it's precisely why we techies tend to get a bad reputation in many businesses. Many business people may find it hard to express their knowledge in the terms that we techies like; much of what they do may be hard to encode in nice UML diagrams, but they do not deserve to be treated like idiots. And that is the distinct impression I got from this book - the authors seem to imply their knowledge is infinitely superior to that of their customers, even when it concerns the customer's own business.
If you read the review again, you should find I do not claim SQL is never embedded within web pages; I simply object to the many unsubstantiated, sweeping statements that litter this book, often left dangling with very little context.
It's all very well in practice, but it will never work in theory.
The stuff which differentiates web projects - in my experience - is
they tend to have very compressed schedules
they are usually very visual - stakeholders can usually see both their own site and a bazillion other sites on the web; a lot of requirements discussions seem to to go something like "make it like amazon when you see the homepage, and like dell when you buy something, but make it nice and light like google and...". This is pretty hard to capture in a requirements document...the visual nature of web projects tends to lead people to assume the underlying stuff is easy to understand too ("I know we're selling books, but if you just make it do auctions like ebay we could earn an additional bazillion dollars")
many of the techniques that help you develop solid code are not easy to adapt to web development, e.g. unit testing, automated system & regression testing, there are comparitively few design patterns catalogued (the "Core J2EE patterns" book is about the bestI've seen thus far, and that is platform-specific), etc.
A lot of web projects are exploratory in nature - both for the business and in the technology used. It's hard to build a solid code base from a prototype.
The shared risk issue is not really specific to the web - it's a common issue with consulting style contracts.
It's all very well in practice, but it will never work in theory.
Where you get that idea from? the link you posted said that I used to say 'web developer' when asked what I did. But I used to do a lot of things... I would help you learn to read, but that's something I used to do, not something I like to do.
The truth doesn't care what I think.
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.
For me - I don't care if someone's looking over my shoulder or not (my last big software development project had plenty of peer-reviews). I just hate being the one doing the looking over the shoulder.
It's probably some stupid thing hardcoded in my brain, but if I'm not actually the one at the keyboard, my mind tends to drift within minutes and I'm thinking of something else completely unrelated. For some reason I just don't remain focused if I'm looking over someone's shoulder. Same with meetings - I have a hard time staying awake in a meeting unless I'm the one presenting or actively discussing.
Oolite: Elite-like game. For Mac, Linux and Windows
I'm the same way. Fortunately, pair programming is an active discussion. It's a lot like the conversation you have in your head while you're writing code, except there are two people involved.
This can be awkward at first, but it's pretty impressive to realize how quickly you can go. If you get stuck, your pair probably has a good idea of what to do next.
how to invest, a novice's guide
Code duplication was not the problem in the case of the project I worked with. Well, it was not the reason for excessive tests at any rate!
Part of the problem was that requirements were changing a lot, and many many tests had to bend to accommodate them. We spent many days in SCM hell where a change to the core object model had to me made and tests all over the place would not even compile... and of course because we were actually trying to produce working code sometimes the tests lagged behind in fixing. To me, that breaks an almost more fundamental rule than test first - Thou Shalt Not Break the Build So That Others Might Work Upon The Code.
Refactoring also breaks tests, and they did a lot of that as well. So between the requirement changes and the refactoring, the tests hardly stood a chance. That's exactly why the business owners demanded they be scrapped - and at the time I have to say I was glad to see them go, because work started getting done and I could go whole days without seeing a compile error from the repository.
That's why I'm saying test-first alone is too simplistic. There needs to be a strategy for test deprecation and retirement, or any kind of large project ends up mired, and create loss of confidence in the project.
The thing I dislike about arguing the merits of XP is that someone always comes along saying "you needed to use the idea of X and the idea of Y, of course it failed as you did not use these ideas". Well, people have used these very ideas and seen them fail, even in conjunction with idea Z that was going to be brought up next. Sometimes a project just plain has bad people on it and is doomed. Sometimes the people feeding you requirements are running in circles and you need to figure than out and reign them in, regardless of what methodology you are using. XP is like a technique that is good and finding local minima and maxima, but to me seems like it can get stuck there and not proceed to the best point on the curve in a complex situation. That's when you need real people, not methodology, to pull you further along.
Personally, my primary methodology is "sniff-first" development. At the start of a project I take a good whiff of the thing as a whole - who will be using it, who is giving the requirements, what is the history behind the need. Then I decide if it's possible to pull off using gut instinct or if it reeks too much to bother with. I've had very few of THOSE pushed at me but I've decided (from experience) with enough Powerpoint slides you can convince management to abandon anything.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's not just changing the database, it may be the data structure that changes, and you get stuck with it.
Now, under some situations, you can define a view that mimics the original table, but when you're adding extra interfaces to an existing product, and you don't have control of the underlying structure, you have to deal with what might happen when it's upgraded.
It'll normally occur when someone gets on a kick of normalization, or they decide that there's a need to handle journaling on a table.
Obviously, you know what sort of an environment you're dealing with, and how likely the odds are of something like this in happening. The more recently you're taken on new staff, or changed management, the more likely this is to happen.
Build it, and they will come^Hplain.
In general, Martin Fowler's "Patterns of Enterprise Architecture" contains a number of patterns for web & business systems.
"Performance Solutions" by Smith et al is probably the best modern (i.e. recognizes OO)treastise on how to design a system for performance.
For the Java world, I would suggest "Advanced JavaServer Pages" by David Geary and/or "Expert One on One: J2EE" published by Wrox.
There isn't much on integrating XML services out there, and there's a lot of freedom.
As for SQL services, the book I found most helpful is Expert One On One: Oracle by Thomas Kyte. It's oracle-specific, but a very high signal/noise ratio.
-Stu