Ian Bicking: the old part of his blog

Zope 3 and Modeling

In comments on this post Martijn Faassen says:

Unfortunately, it has also meant that Zope is not as easy to scale down to small applications. Not being able to scale down negatively impacts the learning curve, and that negatively impacts adoption. We should fix this, and in fact work has been done on it. You're right in that the "hello world" case should be even easier (even though Zope's "hello world" does a lot more than you'd think at first sight).

I assume "Zope" in this context applies to Zope 3; Zope 2 has a funny learning curve. I don't know what a Z-shaped curve is -- I think that breaks my concept of a what a learning curve looks like -- but the curve is one that starts as being really really easy, and then really really hard. Zope 3 doesn't have a really realy easy part (which is fine, since that just led to false starts in Zope 2, IMHO).

But I'd say that Zope's scaling problem doesn't just hurt adoption, it really hurts development too. All applications start out as small applications. I could even invoke some hype word (maybe appending a version number) and say that the New Way Of Development involves lots of small interacting applications instead of large apps.

Good development in the beginning means deferring choices as much as possible and focusing on results instead of abstractions. Abstractions should emerge from your functional goals, and if you spend a lot of time modeling in the beginning then you've made premature choices and designed code that you don't yet understand. You haven't just wasted time, you've introduced a liability.

That doesn't mean abstractions are bad. I'm not saying we should all use PHP; sometimes it's faster to walk than drive, but using PHP is like living in a world where they haven't invented the wheel.

Zope 2 allowed you to start without modeling at all, but down that road led an unmaintainable mess (you can do maintainable code in Zope 2, but it requires up-front modeling in the form of Product building). Zope 3 encourages modeling from the beginning, but I don't think that's the right lesson to learn from Zope 2. It wasn't that Zope 2 was wrong for allowing that simple start, but that it was misdesigned so that there was too much of a disconnect between the simple form of Zope 2 and the reasonably-manageable form.

Anyway, there seems to be a lot Zope 3ers lately saying "hey, what about us?", so there's my $0.02.

Created 07 Oct '05

Comments:

I might add an interesting bit.

I'm now beeing freshly employed the third week at a place where a few people 3-4 years ago choose zope, when it was hype.

At the time, zope 2.6 and python 2.1 was choosen.

It went down as it inevitably would, the whole application is an unmaintainable, horrid, overblown, side-effect ridden, godawfull mess that has the nickname "Fpos" (fucking piece of shit). The only customer who uses it at the moment is running away from it.

I took over the python-dev part there. I'm also new to zope. The learning curve of zope 2 is exactly as you describe it. So aparts from working with really messy code, I learn zope the same time. The learning curve is as you say, a bit easy at the start, and as soon as you relize that the only way to do organized development is doing a proper product, it gets really really hard.

Of course the existing application isn't really suited now to be refactored, because half of it is build on the wrong assumption, much code is just mental masturbation from requirements that have since ceased to be important but it was easier not to touch anything instead of throwing the garbage out, etc. summa summarum, wash, rhinse, seppuku.

Time and time again, when I discuss what the application does I'm told that much of it is easier to do with zope, and that in fact zope 3 is much better now.

I'm just not sure I really want to commit to -An even more horrid learning curve -upfront design -a system that is by nature incredibly rigid because nothing is agile, in effect, forcing me after the upfront efford to get it running wholly never to commit to refactoring easy, thus preventing it.

I feel like I much rather take my chance, and reinvent some wheels but be mobile from there on. Thank you all you zope zealots.

P.S. To all you Zope zealots. By virtue of design of your system, the mess I have to work with actively costs horrid amounts of money. I'm only 3 weeks there, but already we wasted about 5 man-weeks on fixing a simple data-modelling issue, normally a few hours job. That's running costs spend for nothing then maintaining your oh so great system, around 7k$ in 3 weeks and running. I don't even want to imagine how much money that thing devoured in the 3-4 years it's running already. Alone for that this thing doesn't belong into the toolset of any professional, at least if you've a limited amount of time and budget to burn on nothing.

# Florian

I don't think it's fair to brow-beat Zope too much for its past sins. We all know what they are, and I really don't think anyone is defending Zope 2 as being a good web development platform. Experience has made that clear to many people, and Zope 3 very clearly tries to address those issues. It's still useful to consider what exactly have been the problems with Zope 2, and if Zope 3 addresses those problems in the proper way, but they deserve credit for taking their punches and then getting up and trying again.

OTOH, I know from experience when you are in the midst of one of those horrible Zope 2 apps it's hard not to get really ranty ;) It literally makes me ache when I have to work with bad DTML/Z SQL/Acquisition code. When the response to a tool becomes emotional -- and not in a good way -- the brand has a lot to make up for. I think the Zope brand is experiencing that.

# Ian Bicking

I agree with your development philosophy. I just think the basic assumption that Zope 3 encourages modeling and thus you cannot do iterative development with it is not correct. I think it's important for Zope 3 to criticisms into account (and Jim Fulton is actually very good at this in my experience; he even puts up with my sometimes grating harping! :), and I think the criticism that "hello world "is too large is valuable and important. You can't extrapolate from that into a wrong idea of what Zope 3 development is about, however. Zope 3 is primarily about letting a Python developer write proper, clean and Pythonic Python code. See here a longer reply:

http://faassen.n--tree.net/blog/view/weblog/2005/10/08/0

# Martijn Faassen