Development practices

Thursday, May 29th, 2008 | travis brown

This probably falls at least partly under the general heading of sustainability, but I would be interested in a mini-session or discussion about development practices and patterns for small teams in academic settings.

My development team was recently expanded from myself to myself and two undergraduate programmers, and we’re currently in the process of setting up a system with a few basic tools: Mercurial for distributed revision control, Trac for bug tracking, task management, and documentation, and some ad-hoc mod_rewrite sorcery so that we can easily deploy and try out our own revisions and each other’s.

I would be curious to hear about other people’s experiences in similar situations. What worked? What didn’t?

4 Responses to “Development practices”

  1. James Smith Says:

    My development environment (I’m a team of one) is subversion for source management, trac for repository browsing, feature tracking, mediawiki for general web documentation, and wordpress/bbpress for blogging and community.

    I’m working in Perl, so I also use the Perl test environment to do a mix of test driven development and ad hoc development (depending on where I am in a particular set of modules). As code matures, I tend towards test driven development.

  2. Tom Scheinfeldt Says:

    Travis–

    This sounds like a great session, separate from sustainability and project/institutional management discussions. We have been struggling with these issues at CHNM for years. I think the lesson we’ve learned from all this struggle is that development practice is something of a continuous experiment, demanding constant tinkering as technologies, project requirements, personalities, and times change. Yet that doesn’t mean there aren’t good and bad practices, and I’d be very interested to hear about others’ experiences.

    Thanks!

    Tom

  3. Dave Lester Says:

    To add to this, maybe this session could touch on bridging communication between developers and project managers/non-technical staff. Without getting knee-deep in code, what are ways that code benchmarks and progress can be shared? Trac can be confusing/intimidating to people who don’t use it on a daily basis.

    In addition to Trac and SVN, we’ve used Basecamp as a way to communicate internally while using mediawiki for public documentation. Together, how can we make these ‘play nice’?

  4. Liste non exhaustive des thématiques abordées lors des THATCamp | ThatCamp Paris 2010 Says:

    […] thatcamp.org/2008/05/development-practices/ […]