Exactly. The operative words here being "unexpected client requests". No matter how thoroughly you spec things out and try to anticipate everything you will be spending a LOT of time dealing with client saying "OH, but I thought the site would do XYZ..." or "OH, but I thought that it would be better if we did it like this instead" or just plain obnoxious behavior like, "GUESS WHAT, we decided that we need 4 additional reports of sales activity but we can't extend your deadline"...so allow as much extra time as your client will agree to.
Explain to them that by your allowing for a sufficient amount of time and careful planning and testing, you are guaranteeing delivery of a quality application to them, and you don't want to cut corners in any way. Also make sure to get a percentage of payment up front or within the first couple of weeks, that way if things drag out during the client approval phase, you won't be left holding 100% of the bag waiting. And I totally 100% agree, it's nearly impossible to effectively test you own code to production-quality perfection, you need to plan to bring someone else in on that. -- Kristina > Hi: > > It sounded like in the beginning that you had some experience with a > static site, and now you're going to build something that's dynamic > and has a shopping component. > > If I had to pass along any advice about this in general, I'd say that > actually sometimes templating things instead of laying them out > statically can be quicker, in terms of building. But when you move > into dynamic stuff, and especially e-commerce-related stuff, do not > underestimate the time needed for testing. > > You are going to make mistakes. Lots of them. And, you'll have > situations where to get to problem x, you might need to go through > steps a, b and c to get there, which takes time and is mind- numbingly > boring. You don't need to do this kind of stuff on static or simple > sites. And when it comes to e-commerce, it has to work; bugs are not > acceptable because you're dealing with people's private data and all > that, and customers will get nasty when things don't work right. > > (For example, I decided to drop Zen Cart into a project once circa > 2006 or so. It's basically a steaming pile, as I discovered, but > that's beside the point. They had an authorize.net module, which it > turned out after a ton of testing had a bug in it with respect to > error reporting. This couldn't be ignored; I had to go into the module > and fix it. So, if you're using Drupal, and something in Drupal or > some third-party module doesn't work like it should, you need to be > prepared to go in there and get your hands dirty if necessary.) > > So, budget for testing. Whatever time you think you'll spend > building; add on another 200% for the back and forth, the testing, the > unexpected client requests, etc. and so on. If you can swing it, pay > your most anal-retentive friend or perhaps a professional tester some > money to test things for you; just like it's very hard to edit your > own writing, it's often very difficult to spot bugs in a system you > are building, because you naturally tend to fall into certain usage > patterns that don't test everything. > > Oh, and remember to budget for testing. Did I mention that? > > Cheers, > > Marc Vose > http://www.suzerain.com > _______________________________________________ > New York PHP Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > NYPHPCon 2006 Presentations Online > http://www.nyphpcon.com > > Show Your Participation in New York PHP > http://www.nyphp.org/show_participation.php > > ------------------- _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
