[Python-Dev] Interesting blog post by Ben Sussman-Collins

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jun 12, 2008, at 11:41 PM, Guido van Rossum wrote:

> My colleague and SVN developer Ben Sussman-Collins occasionally blogs
> about the social side of (mostly open source) software development. He
> just posted a new one that struck a chord:
>
> http://blog.red-bean.com/sussman/?p=96
>
> The story's main moral: submit your code for review early and often;
> work in a branch if you need to, but don't hide your code from review
> in a local repository until it's "perfect".
>
> Let's all remember this and make sure not to drop "code bombs" on each
> other. :-)

Very interesting article.  I'm short on time and don't want to rant  
(though I likely will ;), but I whole-heartedly agree with the moral  
of the story!

I disagree with some of the details though.  I actually think that a  
dvcs is /better/ suited to transparency, when used right, and when  
coupled with a public open code hosting facility.  Sure, a lot depends  
on social engineering, and I agree with Ben that the tools make a  
difference, I just think that a good dvcs solves more problems than it  
creates.

Also, there are a few things we do at my job that I think contribute  
significantly and positively to our productivity, quality and sense of  
shared community code.  Briefly:

* pre-implementation "calls" - you do not start hacking code until  
you've discussed your design or approach with at least one other  
person, either over the phone or on irc (preferably the former).  Yes,  
there are exceptions but they are discouraged.  This means that when  
you actually sit in front of your editor, you have a much better idea  
of what you are trying to accomplish.

* small branches - we have a strict limit on diffs no greater than 800  
lines.  Yes we have exceptions, but they are rare and pre-arranged.   
Having such a strict limit really forces you to be disciplined,  
organized and very effectively diffuses code bombs.

* everyone can see (lots of) everyone else's code - this is great  
because everyone needs some advice or guidance along the way.  If you  
get stuck, you can push a branch and I can pull it and look at it, run  
it, test it, even modify it and push my own branch for you to see.   
This is /much/ more effective than trading patches, and I don't see  
how this could even work without a dvcs.

* nothing lands without being reviewed - this is a hard and fast rule,  
no exceptions.  Someone else has to review your code, and most  
developers are also reviewers (we have a mentoring program to train  
new reviewers).  You get over the fear pretty quickly, and learn /a  
lot/ both by reviewing and getting reviewed.  Coding standards emerge,  
best practices are established, and overall team productivity goes way  
up.  Small branches are critical to this process, as is our goal of  
reviewing every branch within 24 hours of its submission.

* nothing lands without passing all tests - speaking from experience,  
this is the one thing I wish Python would adopt!  This means the trunk  
is /always/ releasable and stable.  The trade-off is that it can take  
quite a while for your branch to land once it's been approved, since  
this process is serialized and is dependent on full test suite  
execution time.  Python's challenge here is that what passes on one  
platform does not necessarily pass on another.  Still, if this week is  
any indication, passing on /any/ platform would be nice. ;)

I'm not saying Python can or should adopt these guidelines.  An open  
source volunteer project is different than a corporate environment,  
even if the latter is very open-source-y.  But it is worthwhile to  
continually evaluate and improve the process because over time, you  
definitely improve efficiency in ways that are happily adopted by the  
majority of the community.

- -Barry

P.S. I can't leave this without one little plug.  Some folks really  
like the model that a non-dvcs imposes on development, others thrive  
on the freedom a dvcs gives you.  Bazaar is flexible enough to support  
both models, even at the same time.  It's not either-or.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSFLzMnEjvBPtnXfVAQLm3QQAptABUXBoWeshMJAvHno1IDMZavL9D2BG
q9d3wz8O5u2pbvuZyh44w4fhm7w7fscGvmPygifNbjPTVMeUYQUkunuEfWEIzf6B
f6hm1KQm5gi9B4eqSUh3ItIAjGAnkVnCJ8VHeRH/Hff9FZhHqPhtP26LBrecMoho
q0g80DrALB8=
=J936
-----END PGP SIGNATURE-----