Recently, there has been a spate of messages on various blogs concerning "agile content development". Paul Everitt asserts that the Zope 2 through-the-web programming model might be appropriate for tasks that may not require heavy development expertise. He worries that the Zope 3 model - where users need to use files on a filesystem to dynamicize content via templating - might be too heavyweight for "scripters" or "content developers". Both Martijn Faassen and Ian Bicking provide counterpoints. I understand Paul's point of view, and I don't want to pile on, but I do feel like I need to present another countervailing opinion.

I myself took up Zope in the presumed role of a "scripter" because I found it absolutely amazing that I could type code into the old-school Zope.org website in a textarea and have it actually do what I told it to. I could extend the behavior of the website without any other tools. It was something like an ultra-MUD; a self-extensible collaboration environment. I was captivated by this idea, and it eventually led me to working with Zope full-time.

But here's what I've observed over the last six years of programming with Zope and Python: programming is programming. There just is no such thing as a "scripter" or a "content developer" or even a "template programmer". Just like you can't be "a little pregnant", you aren't ever a "small programmer."

By way of example, in 1999, I put through-the-web code on Zope.org to summarize news articles for the "Zope Weekly News" (its chronology was often more complicated). This code was hideous. It would consume a lot of resources and had the potential to bring the website to its knees. Even though I was "just a scripter", my actions were having repercussions that were felt by people who had no investment or interest in what I was doing. Worse, the tools to analyze the performance impact were largely nonexistent. I knew that the code "took a long time to run" and I suspected I had done something horrible, but it worked. And that was all that mattered at the time. It was a hack.

In a "serious" production environment, my actions might have been catastrophic. They would have been immediately catastrophic from a business perspective because the site would have stopped responding for "real" customers. They also would have been catastrophic from a process perspective because it would have been costly to figure out that my actions were to blame for the problem: there was no human-consumable changelog mechanism that allowed system owners to figure out what changed to cause the disturbance. Once some poor bastard had eventually figured out, it would have been even more difficult for him to cleanly and confidently revert to a system that did not contain my changes, because my code was stored in effectively the same place as customer data, and I would be the only one who really knew how to revert the change completely because the system made no meaningful distinction between content and code. Worse, assuming I could be tasked with removing it, I might not rememeber how to remove it, because, of course, I wasn't really paying all that much attention to what I was doing at the time, and, again, there was no human-consumable changelog to remind me. We'd eventually get it worked out, I'm sure, but it would be a stressful time. I'm sure people who have worked with TTW code in Zope 2 hear a familiar echo in this example.

IMO, the Zope 2 programming model created a false distinction: people who used the through-the-web programming model were "scripters" and people who used files on the filesystem to accomplish the same task were "developers". In my opinion, there is no such distinction. Specificially, the effect of code on a system is important and the mechanism by which you contribute code is utterly unlrelated to the effect of that code. You can write bad code in any environment. It's exceedingly difficult (I might even say impossible) to write a system that minimizes the effect of code contributed "through the web", because in practice, the effect of that minimization is to place restrictions on the "scripter" which largely defeat the purpose. For example, most people who begin through the web despise the security machinery in Zope 2, because it actively prevents them from getting completely reasonable things done. On the other hand, it's completely logical to only accept restricted code in "through the web" mode if you make the distinction between "scripter" and "developer". I don't, so as a technologist I consider this distinction (and thus, TTW code) completely useless.

However, from a marketing perspective, the TTW programming story is pretty compelling. It's completely reasonable that any salesperson would like to say that he will provide mechanisms "allow non-technical people to add arbitrary features to the system". The only problem with this is that it's just not true. It will never be true. Nontechnical people might be able to add a restricted set of features to the system ("plugins"), but they just won't be able to change the behavior of the system materially without doing some programming. Nontechnical people apaprently don't want the overhead of a change control system. And any programming that happens which subverts a change control system is doomed by way of my example above. Zope 2 got a bad rap because it did make this promise early in its life. It has paid dearly for it over the last six years, with people in the Python community and elsewhere going out of their way to skewer it loudly and publically. Personally, I think it got skewered mostly because it made these "scripter" vs. "developer" promises and couldn't keep them. If we hadn't made the promise to support this programming dichotomy and had instead concentrated on creating a solid application server with a single simple and sane programming model, Zope might today be more popular than PHP. Zope 3 fulfills this goal now, but it lacks the "sex" of the TTW development model to make it significantly different, and it carries (undeservedly) the humiliating legacy of that model via its name, so it has thus gone largely unsung.

Paul gives the counterexample of a journeyman developer creating a content management system in Zope TTW code that eventually went on to replace a Vignette CMS at a large company.

I actually know this person. And surprise: he is very smart. While he might not consider himself a "Python developer", that's indeed what he is. If someone gave him a pattern to follow that involved files on a filesystem and a change control system, he would happily follow that pattern and succeed again. That said, he might have never gotten there, because there's quite a bit of machinery that needs to get set up in order for him to do that. The real challenge is making this coding pattern easy and comprehensible instead of reincarnating the TTW development model.

I've actually found that in my own consulting practice, the code I create to address their requirements is often of secondary value to them. Instead, my biggest value to them has been to get their house in order by setting them up with repeatable deployment systems and change control systems, and by teaching (and often begging, pleading, and beating ;-) them to use these systems for their own development purposes. In aggregate, this has paid dividends to my customer base larger than any single solution I've delivered so far.