Skip to main content


Showing posts from April, 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 answ…

Pair Programming: The Binkiewicz Pairing Model

If you don't know what pair programming is, read this:
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.
Shared on my google docs site: