50 lines
2.6 KiB
Plaintext
50 lines
2.6 KiB
Plaintext
|
Title: Software in Roller Derby
|
||
|
|
|
||
|
|
Possibly because Roller Derby is full of skaters who are huge nerds,
|
||
|
|
and skater spouses who are huge nerds, there is a lot more software
|
||
|
|
available than you'd see in any other amateur sport. Leagues may feel
|
||
|
|
pressure from nerdy fans, nerdy NSOs, and nerdy skaters, to keep up
|
||
|
|
with the latest in Derby software. But there is no need to use any
|
||
|
|
software at all for a successful bout.
|
||
|
|
|
||
|
|
In my day job as a computer security analyst, I frequently deal with
|
||
|
|
break-ins that were made possible by an over-application of
|
||
|
|
technology. Systems can get so large and complex that nobody
|
||
|
|
understands how they work anymore, and this leaves them vulnerable to
|
||
|
|
attack. I see a lot of parallels with derby here. Bout delays due to
|
||
|
|
scoreboard problems, according to a text message I got from a skater
|
||
|
|
during a 15-minute delay to bout start at Rollercon 2012, are "the
|
||
|
|
most common problem in roller derby".
|
||
|
|
|
||
|
|
If you make your Roller Derby technical infrastructure complex enough
|
||
|
|
that only a few people can fix problems, you are setting youself up
|
||
|
|
for problems in the future. This is why I advise teams to limit
|
||
|
|
technology dependence as much as possible unless they have a
|
||
|
|
"dedicated nerd" at every bout, standing by to fix anything that
|
||
|
|
goes wrong. Something always goes wrong.
|
||
|
|
|
||
|
|
Software engineers get paid to find ways to automate things. So when
|
||
|
|
a nerd sees the scoreboard operator and penalty timer struggling to
|
||
|
|
pause their clocks in sync with the official timer, they think "this is
|
||
|
|
something a computer could do much better!" And they are correct;
|
||
|
|
it's a menial task with microsecond precision: perfect for a
|
||
|
|
computer.
|
||
|
|
|
||
|
|
But their overwhelming desire to automate is precisely why you need to
|
||
|
|
be wary of software engineers when you set up your bouts. We abhor
|
||
|
|
mindless repetition--eliminating it is what pays our bills. But
|
||
|
|
someone is going to have start up your infrastructure for every bout,
|
||
|
|
and most nerds are not going to be able to stick with this menial
|
||
|
|
task for very long.
|
||
|
|
|
||
|
|
Another important consideration is redundancy. Currently, the typical
|
||
|
|
setup for NSOs involves a lot of paper and stopwatches. Inaccuracies
|
||
|
|
are going to crop up this way, sure, but you're not Gotham City either.
|
||
|
|
Your scores are probably not going to differ at all if the penalty
|
||
|
|
timer is off by 2 seconds from the scoreboard timer. However, you also
|
||
|
|
don't have to worry about batteries dying, wireless network dropouts,
|
||
|
|
$800 computers being dropped or slammed into by skaters/refs, cracked
|
||
|
|
screens, etc. About the biggest problem you might face with the typical
|
||
|
|
setup is a 50¢ pen running out of ink, or needing to grab a spare
|
||
|
|
$10 stopwatch.
|