Why We Sprint

I spent last week in Boston, attending an annual code sprint for C-based open source geospatial projects.  I’ve been doing this every year since 2008.  Since getting back, I’ve had to explain the event to several people, technical and non-technical, since the concept isn’t obvious at all.

p3

Open source development of characterized by some features that differ a great deal from traditional work environments:

  • the developers work asynchronously, often in different time zones, usually in different locations,
  • the developers coordinate exclusively using text tools, like e-mail, issue tracking systems, and sometimes instant messaging

Because there is no need to be in the same space with other developers, either physically or even temporally, the barriers to entry to a project are lowered. More people can participate than otherwise.

p1

However, there are disadvantages to working asynchronously and with text communications.

  • asking for help when you get stuck can be time consuming, because your colleagues might be asleep at the moment when help would be most useful
  • issues of subtlety or complexity take a great deal of text to describe, and any misunderstandings on the part of a reader take even more text to correct
  • discussion of emotional issues can lead to conflict due to the limited emotional nuance in text communication

A code sprint is a chance to work for a time with your open source colleagues “the old fashioned way”, face to face, on the same clock.

p2

Because everyone is together, and communications are high-bandwidth and high-fidelity, a code sprint is a great time for:

  • planning and designing large scale changes to the code
  • designing new APIs or new user interfaces, and
  • triaging ticket lists to prepare for release

I usually spend the first half of a sprint on communication-heavy tasks like the ones above. The second half I usually spend heads down on a hard piece of code.

If the right experts are around, code sprints are an excellent time to attack a new piece of code you don’t quite understand. Learning how a module works from the expert who wrote it is far faster than doing it alone at home.

And finally, having lunch and dinner and socializing usually provide the social space for unexpected topics to slip out and get a discussion, whether they be uncomfortable issues like dealing with a difficult team member or just a crazy feature idea that turns out to be not so crazy at all when discussed with the group.

If you have a chance to participate in a code sprint on a project you contribute to, don’t pass it up!

EmailTwitterFacebookGoogle+tumblrLinkedIn