[nycphp-talk] CMS - Estimating Hours
André Pitanga
andre at pitanga.org
Thu Mar 27 17:33:11 EDT 2008
Marc Antony Vose wrote:
> 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.
So, so true...
> 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.
Specially if there's any kind of time constrain. For example, I am
building a small payroll application for a client. Unexpected (or
overlooked) bugs = people don't get paid in time = epic fail.
If one can avoid having to deal with user's sensitive data (credit card,
etc) by using a third-party service like paypal and avoid the possible
nightmares, why not do it?
>
> (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.
Good to know ;-)
> 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.)
Bingo. That's why CMSs can be more problematic than helpful, specially
when dealing with clueless clients.
1. CMS vendors promise the world: innumerable "cool" features, "ease of
use", etc..
2. Client thinks: "wow.. this web stuff is getting so easy. I can have
my unbelievably complex website done in about a couple of days work!"
3. Developers' work misunderstood and unappreciated.
>
> 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?
There was a recent episode of the Boagworld podcast where they go into
detail with suggestions on how to run a testing session. Well worth a
listen.
-André
More information about the talk
mailing list