[Python-ideas] Iterative development

[Chris Angelico]

On Thu, Jan 30, 2014 at 10:56 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> You say - "short cycles" are bad. In agile I'd say - let's try and see why.
> Maybe it's cycles what are bad, maybe it's people who can not sync
> this often, maybe there is a technical problem with communication that
> can be resolved by using right tools.

The very concept of a cycle suggests a system that's more suited to a
business environment than general open source development. Forcing
people to pick up and set down work might be useful in the very short
period just before a version release (I've been seeing some stuff
about Argument Clinic - btw, kudos to the tireless people doing that,
it's a huge job - and how some of the work will be deferred to 3.5),
but most of the time, it's completely unnecessary. In big business,
you might have a couple dozen programmers working on some particular
job; in that two week cycle, each one could potentially put in quite a
few hours. I heard a figure of 80 hours quoted, but I'm dubious about
how many actual dev hours a salaried programmer would get done, in
between meetings and whatnot. Still, could easily be upwards of 50
hours. Forcing everyone to stop and re-check things every fifty dev
hours doesn't sound too bad. Now look at volunteers. Two weeks might
be anywhere from zero hours up to... well, the upper end doesn't
matter. But it could easily be just a single dev hour in that time.
Are you then going to force this person to set aside what he's
partially done, because of some arbitrary break point?

Now, what happens if you take Agile and eliminate the two-week period?
It begins to look very much like a pool of issues on a bug tracker.
You have a pile of stuff to do, someone picks up something he feels
like doing, posts a result back. Hmm, I wonder if that might be what's
already happening... Do you see now why I was, without any experience
of Agile, already dubious about its merits? And that even before Nick
stated from experience that it's not going to help.

Ideas are all very well, but they're useless without some form of
test-bed. The only perfect way to find out if an idea works or not is
to try it, and the onus is on the inventor to risk something for his
idea. Put the theory to work on some project. Once you can point to
some clear advantages *in practice*, you'll be able to recommend this
to other people. So... fork CPython, tell us all how wonderful your
version is going to be, and then show us how, in two weeks, or four
weeks, or six weeks, you can do amazing stuff with a motley crew of
programmers. Then we'll all take notice.

ChrisA