Olympic sports are not usually associated with software developers. Oh, some I know may toss a ball around during breaks from pounding the keyboard, and one programmer of my acquaintance takes joy in chopping wood (I think it's therapy).

But sprinting? Aside from those moments when you've desperately got to catch a bus, that doesn't sound like a geekish thing to do.

Unless, of course, you're talking about a development sprint.

As with its more athletic counterpart, the goal of a development sprint is to get somewhere fast. In this case, the destination isn't the finish line and a gold medal; it's a completed subsystem for an open source project. And the venue isn't a stadium; it can be a hotel, or someone's office, or even a castle.

Sprinting is a form of agile development, and you may see it described as part of scrum development. Basically, it's a two- or three-day focused development blitz, in which programmers pair off and work on specific subsystems. Typically, it involves about ten developers, though some sprints are longer (the Python community tends to go for seven days, with a one day break in the middle, and hosts over a dozen developers, for example), and are more heavily attended. Whatever their size or length, the goals are tightly focused. This isn't the place for massive development efforts; the aim must be challenging, but realistic.

So how does a sprint work?

You start with a project, such as the need to make Blender work in a VR/CAVE environment, or to port Stackless into Python 2.4.2. Then you add a coach, whose job is to set the agenda, track progress, and keep development moving. Recruit participants and find a venue, and hopefully a sponsor who will cover some or all of the expenses, so the sprint is accessible to all who want to attend. And then be prepared to code like a demon.

The first half day of a sprint is spent orienting the participants. They are usually expected to have done a little homework, becoming acquainted with the project, for example, as requested in the agenda for the MobilED sprint. The session could also include helping everyone get the development environment correctly installed, or planning out what each team will work on, or discussing the architecture of the project. Some sprints start with a brainstorming session to decide the approach the sprint will take to a given problem.

Zope sprints begin with a tutorial on Zope development in Python. Programmers then pair off and get to work, using Extreme Programming (XP) techniques, including unit testing. In XP, pairs of developers work on a single computer. One member codes, at any given time, while the other thinks strategically about how the method being worked on fits into the grand scheme of things, and watches for syntax errors and typos. The two can trade off as desired, but only one set of hands can be on the keyboard at any time. This means the pairs must be well-matched to avoid frustration on all sides (or fisticuffs).

Often, one member is a sprint veteran, mentoring a newcomer. It's a great way to get more people acquainted with a code base, and ready to contribute more to the project. The coach is always available, so a team that get stuck or begins to digress from the goal can be quickly extricated and set on the right path. Daily status meetings keep the overall project on track, and most sprints have a wiki that (if updated) provides a record of the exercise.

By the end of the sprint, the plan is to have complete, tested, documented code that can be integrated into the project.

While coding is going on, it's intense, but there's always playtime too. Check the agenda of a sprint, and you'll see all manner of social events for weary geeks in need of a revitalizing party.

Organizing a sprint is like organizing any conference. There are logistics to think of — housing and feeding even a small horde of developers can be a non-trivial task, even if they are willing to unroll sleeping bags in a quiet corner! Finding the right coach is critical, and even little things like power for laptops can cause Moments of Interest. The folks at Drupal, who have put together a number of sprints, offer guidelines for planning a successful sprint.

And by the way, yes, sprints have indeed been held in a castle (bet you thought I was kidding!). In 2005, Goldegg Castle in Austria was home to a Plone sprint. Not a bad venue for a few days of intense code generation!