Thursday, April 21, 2011

Remembering the little things: a backlog for inactive projects

This came up at work the other day: how do you capture those "little" features that you want to take care of next time you modify an existing (but currently un-funded) codebase?

We're using an open source project by Jasig - the central authentication service. We have a suite of different products that use it, and we want it to act as a single sign-on solution for users who have a subscription to more than one product in the suite.

A problem cropped up last week when I discovered that it was loading some information from a table at start-up, but didn't refresh the data until a restart. It should be a pretty simple task to add a cache that would reload the data every 30 minutes or so, making it simple to add another product to the auth service.

I didn't want to make a change right then because we have enough going on this week on my current project, but I didn't want to forget about it next time we dust off the codebase and add another set of features. The answer is pretty simple: we use Jira as a "story bucket" for both new features and to keep track of bugs. I just needed to create a new project for it, and dump the story in.

Pair Programming: The Binkiewicz Pairing Model

If you don't know what pair programming is, read this: http://c2.com/cgi/wiki?PairProgramming

Bill Binkiewicz is one of the many top-notch developers at my office. He's also a pretty humble guy, and as far as I know, doesn't blog. He didn't even put his name on this, but that's OK - I'll add it for him.

I'm finding this to be a very useful model on my current team. The document centers around how to choose who should pair on a given problem, based on their interest and experience with the technologies and business domain.