Development methodology (Re: [Zope-CMF] Future CMF) (rant)

[Doug Hellmann]

On Monday 07 October 2002 2:56 pm, Lalo Martins wrote:
> On Sat, Oct 05, 2002 at 10:21:11AM +0200, Paul Everitt wrote:
> > Speaking of "Future CMF" (and thanks, Erik, for relabeling the subject
> > line), Jim's announcement of proposal on this topic has received no
> > comments:
> >
> >
> > http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/
> > ContentManagementProjectsForZope3
> >
> > Zero, zippo, nada.
>
> <rant>
>
> Have you noticed how Zope3 development has slowed down a bit?
>
> IMO the community development of Zope3 (and other Zope-related projects in
> general) is all wrong. The metodology is too documentation-oriented, there
> are lots of virtual-paperwork involved in projects that otherwise would be
> simple.

<snip>

The single biggest complaint developers new to Zope have is the lack of 
comprehensive, easy to discover, in-depth documentation.  A methodology which 
calls for documentation before implementation is a pretty good way to remedy 
that situation, over time.

> Community-oriented open-source development is not compatible with ISO9001.

I thought ZC was using XP?  :-)

> I develop stuff because I have a need to fulfill and/or because I find the
> challenge fun; I do not want to identify use cases, risk factors and
> whatnot before I implement something I already know how to do.

Thinking ahead can be slower, but also very useful.  Just because you know 
one way to make it work doesn't mean you know the best way.  It *certainly* 
doesn't mean anyone else would know how to *use* the fruit of your labor.

> Additionally, most developers have little to no interest in commenting
> other people's ideas before there is some code to test.

So maybe the community needs to be reorganized.  What if there was available 
a pool of "designers" (instead of "developers") available to comment on 
designs?  I personally have very little time to write or review code, but I 
may have time to read and comment on design plans.

> So... respecting the current methodology, I would propose and open for
> discussion a path to revert this situation. I further propose that this
> path is tried experimentally on Zope3, or alternatively on CMF1.4.
>
> My suggestion is that we move to a model more similar to the PEP system.
> The *first* artifact necessary for a project is a prototype. If the author
> doesn't yet know the details, it's ok to raise a discussion on the list or
> IRC, but then it isn't yet officially a "project", just a discussion.

Providing an implementation prior to a discussion of the design would not
necessarily produce good designs, just faster implementations.  Maybe we have 
different goals, though.  I'm looking for a stable tool that does what it 
claims to do and makes it easy for me to build what I need.  A rapidly 
evolving platform with little documentation isn't going to meet those needs.  
A well thought out system which allows me to plug components together as they 
evolve, and maintains backwards compatibility, does meet those needs.

PEPs work well for Python because in the end there is a very complete 
reference manual available to users.  As new features are added to the 
language or standard libraries, the reference material is kept up to date.  
The Zope book seems to be starting to serve that purpose for Zope, but there 
is still a long way to go.

The recent shift in attitude from "wow, look what we can make it do!" to 
"let's make it easier to figure out how the heck to use this thing" is a Good 
Thing.

Doug