[nycphp-talk] CMS - Estimating Hours
Marc Antony Vose
suzerain at suzerain.com
Thu Mar 27 17:08:36 EDT 2008
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?
More information about the talk