homepage/content/papers/derby-software.md

91 lines
3.9 KiB
Markdown
Raw Normal View History

2017-07-09 18:13:41 -06:00
---
title: Why you shouldn't use Derby Software
2022-09-04 16:59:13 -06:00
section: derby
2017-07-09 18:13:41 -06:00
---
2014-01-21 19:54:23 -07:00
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).
-----
2012-09-11 22:57:01 -06:00
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
2014-01-21 19:54:23 -07:00
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.
2014-01-21 19:54:23 -07:00
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.