[nycphp-talk] CMS - Estimating Hours
ka at kacomputerconsulting.com
Thu Mar 27 18:09:02 EDT 2008
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
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.
> 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
> 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-
> 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
> 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
> 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,
> unexpected client requests, etc. and so on. If you can swing it,
> your most anal-retentive friend or perhaps a professional tester
> 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?
> Marc Vose
> New York PHP Community Talk Mailing List
> NYPHPCon 2006 Presentations Online
> Show Your Participation in New York PHP
More information about the talk