After a year and a half as the sole developer on a content management project, where my programming was limited to writing utilities to assist with data loads and *shudder* writing OScript, it is freakin' fanTAStic being on a real development team again. And an agile(ish) one at that. It's great being able to discuss nice meaty problems like how to layer your application or how best to deal psychologically with the frustration that is the VSTS merge tool.

Now this being my first real agile experience (or at least the first one that's been officially called that), I'm not totally familiar with the conventions. But it seems to me that agile shops could benefit from a role that I'll call The Littlest Hobo, for lack of a better term. That is, someone who goes from project to project, lending a hand where pain points exist.



Maybe tomorrow, he'll wanna settle down.
But until tomorrow, he'll just keep codin' on

Many projects may have something like this in some regard. I imagine the scrum master plays this role for higher level impediments but I'm thinking at a more detailed level. Someone whose sole job is to pair with a developer for a morning on a task, then review code on a different project in the afternoon. The next day, he or she would examine the build process of a third project and see if it could be improved (and it always can). Another time, perhaps he or she could mentor someone on ReSharper shortcuts while they code.

Essentially, I'm thinking of someone working outside of a single project who can provide an outsider's perspective during the development process. And it doesn't necessarily need to be one person's full-time job. It could be a role that is passed around among senior developers every week. It doesn't even need to be a role that is fulfilled every week either. If you have a small group, maybe one person takes it for a week, and then it stays unfilled for a couple of weeks.

The impetus for this idea was an upcoming code review. Few people will deny the benefits of a code review in theory but in practice, I've been on both sides of the review and very often, there is no "ideal" time for a code review. Often, one or both of the reviewer and the reviewee are none too pleased to be ripped away from their work even if we recognize that it is something that needs to be done. It's difficult to coordinate a review time that isn't "crunch" time on one project, let alone two (presuming the reviewer is on a separate project).

That's where The Littlest Hobo could help out. This person's schedule could be almost set in stone save for the specific projects and people involved. E.g. Tuesday morning: Pair with someone. Tuesday afternoon: Review code on some project. Wednesday morning: Increase code coverage for some project. Thursday afternoon: Code review. Monday morning would be reserved for filling in the blanks where it says "some project" or "someone".

Personally, I think it would be a helluva fun role. Not full-time, mind you, but once every couple of months it would be a nice break from the ol' day-to-day, doncha know.

And for you nostalgic Canucks who are already singing it in their heads, here's the theme song.

Kyle the Nomadic