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

[Christian Theune]

--LQAwcd5tHl0Qlnzi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Lalo Martins <lalo@laranja.org> [021008 23:01]:
> On Tue, Oct 08, 2002 at 01:25:47AM +0200, ct@gocept.com wrote:
> > Hi.
> >=20
> > Just giving my 0.02E, I strongly am joining the responses that tell:
>=20
> I understand this position, but I still feel our methodology is sub-optim=
al.
> We can be very strict about what goes in the CVS trunk, if we want. Perha=
ps
> even more strict than we are now, as in, requiring *usable* documentation
> (as opposed to, like I said in other message, "process documentation").

Hmm. But process documentation is what we need because of a very ...
fluing (flowing?) network of ppl. (I mentioned that in a later mail).

I still only can say what I'm *feeling* about. From the point of my
professors, I would say we of course need *both*. Now is the question
how we can make the most effective use of our limited resources.

    -   a) Getting developers to write code is "easy". So you ask that
    we should concentrate on developing code.

    -   b) Getting ppl that document is "hard". So you ask we should try
    to focus on what we *can* do: writing code.

What I learned from the first year on highschool and lot's of practice
in my own business, I say that this just won't work out. We would end up
with something like Zope3.__of__(Zope2). ;)

You ask for Documentation about the coding artifacts, but developers
aren't very good on writing those most times too. Developers (more ore
less intuitively) are relative good on writing process documentation.
It's a fact that it's more fun to write code, but the really interesting
thing is the theory that makes the code actually work. Almost everybody
can code. Inventing complex, interoperating systems like Zope 3 isn't
something you wrap up on a post-it note. I always had a good feeling
coding/doing things for Zope 3 (I only was doing 2 things) because they
were documented in front of the actual coding work. Everything was clear
how it would go, (Maybe interfaces were defined. That's something that's
a probable meeting point on the discussion about prototyping) so other
ppl already could rely on the documentation we produced and could go on
writing something that leverages our non-existing code already.

Hope I'm not too confusing.
Christian

PS: CCing the Mailinglist again ...

--=20
Christian Theune - ct@gocept.com
gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt
tel.+49 3641 511586 - fax.+49 3496 3099118 - mob. +49 179 7808366

reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])

--LQAwcd5tHl0Qlnzi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9o1UZdUt9X/gknwIRArBfAKDEXkauMCwfUkt2FrMOdmGGG0SSQwCcChx7
cLysWi4zC+VwJ7Vd/UPm4aE=
=b5oK
-----END PGP SIGNATURE-----

--LQAwcd5tHl0Qlnzi--