Flashes of Panic

Last year, I was the Clerk of Course at the Amherst Invitational. (For some reason, I always want to tack, “of course, of course” on the end of that job title.) For two years I scored the meet manually (using large sheets of oaktag and a pocket calculator) near the finish line, a process so clumsy and error-prone that both years I ended the day lobbying for a computer.

We scored six races ranging from sixty to a hundred and sixty athletes, and while cross-country scoring is relatively simple on its face (you sum the places of the first five runners from each team to get team score, and low score wins; a “perfect” race, sweeping the top five spots, scores fifteen,) things get very complicated very fast when you put it in practice. For example, imagine a team without enough runners to score (fewer than five.) They should be removed from the finish order before scoring everyone else (but the athletes should be listed in the results, of course.) Likewise, while runners six and seven count as “displacement” (their places don’t contribute to the team score, but they can increase other teams’ scores by beating other scoring runners, and ties should properly be broken by the sixth runner’s place,) a JV race with more than seven runners per team can be a nightmare of non-scored runners when you’re scoring manually.

So last year, I got a promotion and a hardware upgrade. My position involved glomming together a web interface to allow coaches to enter their teams online, then dumping that data into a file which I could then import into the meet management software. Then, on race day, I ran the meet management software near a power socket inside the gym, rather than being outside watching the races like a good fan. I used one of our geriatric laptops from work, and we wound up doing quite well, all in all.

This year we’re skipping the web entry step (which required too much hand-holding for the other coaches last year,) and doing the data entry directly into the meet manager ourselves. The hitch this year is that I’ve got a prior commitment that weekend, so someone else will be doing the scoring this year.

Last night I got all the pieces together to walk the coach through the process tonight. He’s a Mac person, so he’s “borrowed” a Windows box from work to score the meet. I think he’s recruiting someone else to do the scoring, so I may have to do this again. This is a good thing; I don’t want to be the SPOF of meet scoring.

Meet scoring is essentially a database problem, and most of the many packages out there are just database applications bundled with the appropriate forms and reports. The data structures are interesting and mid-range complex, but nothing that couldn’t be done as a semester-end project in any database management course. (Before you think it’s “simple” based on what I’ve described above, consider a track meet, or even a swim meet.) In fact, sometimes I wonder why nobody has put together an open-source version.

(The reason, probably, is that this sort of application cries out for the sort of “small pieces loosely joined” system which is easily cobbled together from the utilities installed by default on a unix or Linux system, but needs something painfully monolithic on a Windows system, and most hackers would rather “roll their own” in *nix.)

(Another reason might be the kind of peripherals you need to support; there are plenty of data-entry gizmos like bar-code readers or finish-line cameras to plug in, plus touch pads for swimmers. We won’t even start with the Lynx folks, but don’t think I haven’t looked with interest at their job listings before.)

Still, I’m going to have an interesting time of it trying to explain this without getting in to the broader concepts of database entities, constraints, etc. I hope I can communicate more than just the step-by-step, “First you do this, then you do that, and don’t worry about why.”

Now playing: Ride from Dandys Rule OK by The Dandy Warhols