Flashes of Panic

There are a lot of ingredients that go into being “good with computers.” One, as discussed in a conversation the other day, is the willingness to try a number of different approaches to troubleshooting, and to keep tinkering until something works, rather than persisting in a “right way” that isn’t working.

Another is being willing to pay close attention, to the point of obsession, to the quality of input, because that’s really what controls output.

This morning, as I sat on the floor of the Medford city council chambers waiting for the awards for the race we ran, I saw a reminder of this principle in action. A worried-looking woman said to another runner, “The results and the entry database aren’t lining up right. It’s all messed up. We aren’t going to be able to do the awards.” Eventually they admitted the confusion in a general announcement, recognized the male and female overall winners of the 5k and 10k, and skipped directly to the raffle, promising to mail any other awards.

They have the results posted online now, but it’s plain that they haven’t fixed whatever was wrong. There are six women listed finishing in front of me, but only one did, and she—the one recognized as the winner—is listed as the fourth-place woman. And there’s a five-year-old “male” named Eleanor in front of me; somehow I question that. My bib number, age, gender, etc. are correctly listed, and if I check the place I think I got, it correlates with the time on my watch. It’s hypothetically possible that I placed second in my age group, as listed, but I don’t really trust the listed results because they show the wrong women’s overall winner, and my incorrect time. The 10k results have a woman winning the race overall, and appear to have even less relationship to the reality of that race’s finish than the 5k results do, though again, places appear to match times correctly.

Results of road races and cross-country races tend to work as a three-table database. There’s an entrants table, which has the name, age, gender, etc. of each entrant, along with the assigned bib number. The bib number isn’t usually the primary key (the table may be useful before numbers are assigned), but it can function as a key. At the finish line, two more tables are generated. One is an ordered list of bib numbers, which form a two-column table where the first column is the ordinal number of finish. The last table is a similar ordered list of finish times. In both cases, the ordinal number column is a key, but so is the value column; they’re normalized tables, “The key, the whole key, and nothing but the key, so help me Codd.”

The results printout, therefore, is a join of these three tables: the first and second are joined on bib number (producing an ordered list of entrants) and then the third is joined on finish place, assigning times. The second table, the ordered list of bib numbers, is the glue which assigns times to finishers.

In the case of this race, that table got botched somehow. Maybe the numbers weren’t keyed in the right sequence; maybe somebody shuffled the list somewhere. The bib numbers are hooked to the right runners, and the times are hooked to the right places, so those tables are OK.

Whenever I’ve participated in race scoring, I’ve seen the near-paranoid care taken to preserve correct finishing order. At yesterday’s New England Division III regional, where finish order (which determines team scoring) is paramount, they had four different systems in place in case one failed. On the other hand, I think I recall the organization which handled scoring at today’s race being associated with my last marathon, which still holds a special place in my memory as a race where organization failed in the most basic ways—including the production of accurate results.

Now Playing: Window from Inarticulate Nature Boy by Josh Clayton-Felt

Technorati Tags: data, medford, race, running, troubleshooting