Introduction
I just (21 Jan, 2014) found this half-written unpublished essay on my hard drive. There’s some good stuff here, even though it’s not up to my usual standard for publishing. Maybe it will help somebody convince their league to keep things simple. Maybe I’ll rework it to suck less (probably not).
You don’t need technology to run a derby bout. It can make things a little easier on the NSOs. Fans might appreciate rinxter online updates. But the focus needs to be on the game, not your awesome technological infrastructure.
Main points:
-
Shit breaks. Complicated shit breaks more, and needs bigger nerds to fix it. Stay simple, and you can recover quicker.
-
Low-tech solutions are cheaper, more durable, and easier to repair or replace.
-
Integrated solutions are awesome right up until the point when they fail. A failing scoreboard can be fixed while the bout continues. Tie your official clock into that system, and now failure means nobody plays 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 chase down bugs, 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.
Technology has a place in derby, sure. It can help a lot if you bring it in at a rate that you can handle. But remember that you can do just fine without it. This is coming from a guy who’s created three or four derby software packages, and two derby hardware gadgets.