[Python-ideas] Iterative development

[anatoly techtonik]

On Thu, Jan 30, 2014 at 3:49 PM, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

The cycle is needed when you need some kind of visibility in the process.
For business environment it is critical, because it has to control the
spendings. For open source environment it is critical for people, because
they need to plan their time.

> 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),

Again, it is not forcing anyone. It is just a process. You are free to fail
you development goal. It is not a business - there is nobody to fire you
or say that you're underperforming. There is no heroism either. If you do
not know your development pace, you can try and measure it, if you do
know, you just realistically state what are you working on and if you
need help with that.

> 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?

Single dev hour is ok if you reached your goal. That's the point.
You set the goals - you reach them. If you didn't reach them - you
analyze and see what could be done better. It is all in relaxing and
free manner, unlike the bloody corporation culture. You may invite
other people to join the fun. People can find what are you working
on and propose help.

This is the process.

> 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.

That's a crowdsourced development, not a team work in distributed
environment. And there is no place for team to appear if everybody looks
at a big pile of garbage and chooses the shiny metal plate that is
precious only yo him.

The environment you've described is not encouraging team birth and
collaboration in any way. More than that - it looks like people would even
oppose if commercial development teams would propose their work. In
the past it happened already with "unladen swallow" project. Current
development process couldn't munch the result if this work, and people
didn't even try to adjust the process to make the future efforts possible.

> 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.

I don't want core devs to accept this process at all. I don't want to sell it
to them and I don't want them to follow it. =) It is completely optional,
and I just don't want them to make more obstacles to new people who
would like to try these.

It may happen that resistance to change for open source projects may
be bigger than in organizations. I just want to make sure that people
aware that applying agile methodology to open source development is
possible and I am inclined that it brings more positive improvements for
the Python itself than de-facto development processes.