NYCPHP Meetup

[Kristina Anderson]

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
> 
> 

-------------------