[nycphp-talk] CMS - Estimating Hours

André Pitanga andre at
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 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 


More information about the talk mailing list