[nycphp-talk] CMS - Estimating Hours
lists at nopersonal.info
Thu Mar 27 17:38:43 EDT 2008
Yes, I've got 11 years of experience with static sites and I've even
done some simple custom CMS work, but I've never tried integrating an
existing CMS package with a bunch of other stuff. My PHP skills are at
the lower end of intermediate, so this is going to be a challenge &
learning experience for me.
Your practical example and advice re testing & other possible gotchas is
much appreciated (as is your humor). The only other dynamic site I've
worked with was for a real estate agent. I used Open-Realty and
modifying the templates was a PITA--it wasn't difficult, just (as you
mentioned) mind-numbingly boring having to pick through gobs of PHP code
to find the template bits & HTML, make a change, upload, test, try
Marc Antony Vose wrote:
> 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?
> Marc Vose
More information about the talk