This is a rehash of a post from the last blog but I was reminded of it again after reading about Chris Ortman's Developer Exchange Program, an idea with promise and I'll be watching to see how it plays out. (Sorry I can't participate, Chris. Have a hard enough time convincing companies to take on a remote developer, let alone one who's tag-teaming.) And I don't mind revisiting it because 99.8% of you haven't read it yet and the other 0.2% are Canadian, and will jump at the chance to talk about a piece of Canadiana that few outside the country are aware of.

In Canada, there was a long-running TV series called the Littlest Hobo. In it, a very well-trained and patient German Shepherd roams the countryside helping people out as the situation warrants. Kind of a pre-cursor to Quantum Leap but instead of the hero doing some sort of phase shift from one situation to another, he just kinda trots off. Plus he's a dog. The theme song is so sing-along-able, it's practically a bar song. (Everybody: "EVERY STOP I MAKE/I'LL MAKE A NEW FRIEND!").

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

As applied to software, this would be a useful person to have, particularly in an environment that has several projects on the go at the same time. The idea is that someone would go from project to project, lending a hand wherever they were having trouble. Taken from my original post:

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.

I haven't formalized the role much more than this in the six-odd months since I posted it. Except that I'm convinced the role should be passed around to different people. And that it would probably be practical only for about a week each month, depending on how many projects you have on the go. If it's five or less, I can see it becoming a burden having to deal with someone dropping in on your project once a week.

But then, the role shouldn't be too ceremonial either. That's not the way of the hobo. If you go to a development team one afternoon and say "How can I help?" and they say "Not now", don't force yourself upon them. Move on to the next project.

The short duration is important too. It keeps the hobo from becoming too entrenched in a project. Keeps the focus on quick tasks that the team always needs done but that no one has bothered to take the time out to do.

I'd have to see how the idea plays out in practice before I fully endorse it. It kinda sounds like one of those "good intentions" dealies, where the idea has merit in theory, but in practice, you end up passing around the kid who's always picked last for sports. It's definitely one that could fall prey to a crappy corporate culture.

Many companies have someone who kinda, sorta plays this role, even if it is not formally defined as such. In these cases, I say formalize it and pass the baton around a bit so that it's not always the same person.

So I look forward to the day where I can test it out. In the meantime, do yourself a favour. Become The Littlest Hobo in your organization today.

Kyle the Nomadic