Sunday, January 13, 2013


It's a race weekend here in Alaska, with the big one being the Copper Basin 300.  It bills itself as the toughest 300 miles in Alaska, and it's lived up to that in the past.  It was actually cancelled because of the lack of a race board, then they were able to get a group together in the fall to make the race happen. Some things are falling through the cracks, notably timely race updates and accurate data.  

I think it is not sufficiently well-appreciated in Alaska that distance dogsled racing has acquired an international fan base and that there are a lot of people out there hanging on race updates.  For whatever reason, keeping the data flowing does not seem to be a priority.  We've seen it in a few races and we're seeing it in spades with the CB300, with the added problem of incorrect times and a lot of arithmetic mistakes.

At some point I'll post about using spreadsheets to handle race data.  There's absolutely no reason to do the arithmetic by hand, and spreadsheets have a surprising range of functionality, from time-based calculations to summary statistics to plotting data.  There are a few tricks I'd like to write about.  But ... the CB300 is clearly doing it the hard way.  And the slow way.

Anyway, there have been questions about network connectivity at Copper Basin checkpoints.  I have no idea, but I'm not sure people are fully aware of the options available to them.  This is the main thing to remember: 

You can frequently get wireless SMS messages out when you can't make phone calls or connect to the internet

It was also race weekend here in Two Rivers, with our postponed Solstice 100 finally taking place.  What we found worked extremely well was to have someone in a location with good connectivity updating our online spreadsheets, and someone at the checkpoint sending email or SMS text messages when a team arrived or left.  This is obviously not an option when you've got no connectivity at all (this is where ham radio or a satellite phone might be a way to go), but it became pretty clear pretty quickly that relaying the data out to someone with good internet connectivity works extremely well.


  1. main thing to remember is it's an ALL volunteer race and everyone is doing the best they can. Maybe you should cover the race next year ...I know I'm done being bashed for all my work. You think you know what's going on and you just blast people out of the water. Lame. No public skills

  2. I was out this afternoon and thinking about writing a post similar to Melinda's, though not based on the Copper Basin, but on some experiences in our low-profile neighborhood 100-miler yesterday. Then I came home and she had already written the post. But there's one point I that has been becoming clear to me: It's never one person. I have no idea how you guys at the CB are set up -- it's been my experience that the people on the ground, those data collection and communication is the base of all public real-time updates, haven't embraced their role in all this, and they'll only do if the race organization is aware of how everything hangs together and what it takes to make it happen, well, then things will get hard. I'm pretty much 100% sure that while there's always something that can make the life of the front-line web person easier, blaming that person is surely the wrong way to improve things. Take even such an obvious point as the use of spreadsheets for arithmetic. If all the race organization expects from a web person is to put whatever they get online and is not responsive to questions back ("this data point you sent me makes no sense") then the data quality will fall apart. And I'm not saying that's what the CB is doing at all -- this is a theoretical example. Figuring out who must be empowered to do what exactly is hard.

    1. not to mention all but 2 of us are a NEW crew at the CB this year.Thank you Chris for your reply. Frustrating for me to say the least.

    2. I'm sure it is, and it has been for me as well, even though probably for different reasons. For what it's worth, I've been solving operational problems in computer-related areas for years for a living and am quite aware that the hard stuff is often what looks easy. Getting arithmetic right sounds like something anyone can do, except if you have reams of handwritten time sheets to translate into correct runtimes. Then you have to think about tools and processes. I don't know anyone in this area who doesn't constantly say, "Ok, we're doing fine with THIS part but we suck at THAT one. How can we get to not sucking?" And of course it helps to have enough of a skin to distinguish constructive advice from friends from idiots who like assigning blame.