[Zope] Costs of implementation

[Cary O'Brien]

> I am trying to motivate the use of Zope / Zcommerce, and to do this need
> some timing ideas - Does anyone have thoughts on how long (man hours per
> expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and
> Co's EMarket) and to a successful transaction?
> 
> Hopefully this will be of general interest for anyone doing a business case
> or planning, so if you have any thoughts on "we expected x by experienced y"
> it should make interesting reading.
> 

Zope has a sigmoidal[0] (is that the word?) learning curve.  Out of the box it
installs *very* nicely on unixen, and you can clickety-clickety around and
create folders [1], upload files, and set up a static web site pretty
easily.

Then you want to connect up a database.  My experience is limited to
PostgreSQL, but the sigmoidal shape repeated itself.  The database
adapter dropped in without a hitch, and simple queries worked great.
I implemented a reasonable database-backed problem tracking system for
our company last summer in about 2 weeks of fiddling around and 2
solid weeks of implementation (my sql/web skills are ok, my python
knowledge is um, a work in process).  And it has been operating
flawlessly for over a year.

But then comes the steep part.  Anytime you mix several languages
inside themselves, things are hard.  Productive as hell if you get
it write, but hard.  With Zope you've got to wrangle HTML, DTML,
Python (at least for expressions) and SQL if you're connected to
a database.  A misplaced quote, comma, or bracket can throw you
off for a long time.  Ok, we've got the source, but debugging 
Zope stack dumps can be a pain.

But after a while it gets better.  I *think* I'm starting to at least
see the shallow part of the learning curve at the top, where you can
do things like implement a ZClass container that acts like a Dynamic
HTML layer in an afternoon.  Which I did, but only after 3 very bad
false starts.

The base Zope documentation needs some work.  The HOWTOS and TIPS
have saved the day many, many times. 

But back to the business case.  My feeling is that even with the
steep bits of the learning curve, Zope is a big win for implementing
services.  Zope wins because if you do a good job getting things
working, you have an incredibly flex able system for dealing with
the inevitable never ending stream of change requests.  And thats
where the payoff is.  At list I *hope* so :)

-- cary

[0] S-shaped.  like this ( _/-).  shallow/steep/shallow.