Cookies and Capacitors

Digitizing Forensics: A call to modernize speech and debate from judging to tabulation

Sun, Feb 12, 2012 at 6:54PM

A look at current practices

In Wisconsin forensics, at least the regions in which I have participated, judge and tabulate results of participants by hand, using little more than pen and paper. It’s been this way for ages; no doubt, because the administrators managing these events were taught this way, like their forefathers before them. Even though this system has “proven” reliability, students can still be cut short when it comes down to counting votes.

The current “pen and paper” system is inherently flawed. What security does it provide? What parity does it offer?

Student codes

Most speculatively, and at the lowest level of hierarchy, bias is introduced by judges. If a judge doesn’t like a student’s school district, or would rather propel their own district ahead by misjudging others, they can easily influence results. Everything starts with the judges. In order to minimize this bias, current codes must be abandoned in favor of UUIDs (universally unique identifiers). Let’s look at an example:

||^^^_ Student number
|\____ School code
\_____ Category code

With the current syntax of a participant’s code, a judge certainly wouldn’t have a difficult time discerning a participant’s school. But sometimes “mistakes” in judging are unintentional.

Unintentional mistakes

Student codes are often misspelled when judges copy them from one sheet to the next. This kind of error is extremely easy to make: just look through current judge forms. Often, one can find mistakes without a minute’s glance. These mistakes carry into the tab room.

Participant results are tabulated in the tab room. Here, mountains of paper judging sheets tower over tabulators, working hard to enter massive amounts of information into an archaic spreadsheet (I speak of the one devised by an Appleton, WI coach many moons ago). When this information exchanges hands so many times, it plays a bit like a game of telephone. Scores are recited and copied over and over, until the end result may or may not be what was originally stated. Now, I’m not saying that it’s a massive problem, but it happens often enough where it should be mentioned. Easy mistakes, like this, shouldn’t be made at all; it’s extremely unfair to hard working students, who are shortchanged.

All of this is just a peek at where mistakes are commonly made.

A digital model


For decades, computers have aided humans in preventing mistakes. Not only that, but they have also increased productivity. One may argue that “increased productivity” takes some of the fun out of things, and while this is true, I shall address it shortly.

What Wisconsin forensics needs is a computer interface to aid in judging and tabulation. Here’s what can happen during a meet:

At the beginning of forensics season, a computer (a central server to all schools) will assign a UUID to each student, and keep this ID in its database. Once a student receives an identification number, QR codes may be printed out or made into keychains (this is a potential source of profit, which can be further referenced in the section titled, “Where I come in”).

At the meet, judges use computers to submit electronic forms instead of paper forms. Students may participate in any order, and once it’s their turn, the computer’s webcam scans the student’s QR code which loads a judging form. This form contains information like the piece’s title, student’s picture (to make it easier to remember pieces) and pro/con comment areas. Once all the students have presented, a new page appears with the students' pictures, piece titles, and comments the judge made earlier. Students may be dragged and dropped in order of best to least performance. Pictures and comments help the judge remember a student.

Once every room is submitted (or at least an entire category) the computer tabulates the results and provides a power sheet automatically. Because of the computer’s nature, students may be alerted via text message or email that they powered, and their powering performance time, as well as alerting coaches that their student has powered.

Power room judging is identical to normal rooms.

So, simply, the swing of things will remain very similar to judges. Unlike the current system, though, it is less error-prone and more anonymous.

Technical reference

The server

The digital system will be a standard LAMP server, most likely running in the cloud on an Amazon EC2 virtual server. This way, uptime is maximized and access speed is increased. Not only that, but instances may be restarted and expanded based on real-time needs (i.e. many schools may be competing one weekend, but not the next). This reduces total cost of maintenance.

On the server, MySQL will be used for its versatility and relational database functions. Not only that, but it’s free for commercial use.

Login and judging forms will be written in PHP, while tabulation is done with Python or Perl.

Participant identification

Participants will be assigned UUIDs at the beginning of the season. It will stick with them throughout every meet. They look like this:


Since this is a permanent ID, students can have profile pages with their participating categories, piece titles, a photo, and with recent reviews by judges at past meets. Having all this information in one place is at great convenience to students, so improving their performances won’t be as time consuming (but it’ll still be fairly time consuming; greatness comes from diligence).

Judge’s tools

Judges will need to be assigned a laptop with a webcam. In special scenarios where webcams are unavailable, a UUID must be entered manually. Verification can be performed to ensure the ID belongs to the student in question.

Where I come in


I plan to program this “digital tab room” throughout the next year. Providing fast development, it may be done in time for an autumn practice run to work out bugs.

Development donations are welcome; soon, I will put up a product page where individuals may donate and with more product information.

My rewards

I see this as two things:

  1. A way to help students become better communicators.
  2. A business venture.

Students don’t deserve to be shortchanged, and I need to put bread on the table. I’m not looking to get rich from this idea, only make enough to get by (comfortably). In addition, this is great experience for me. In the future, I hope to work for a major tech company (hello, Apple) and since I’m not getting a formal secondary education, experience is extremely valuable. This venture provides programming experience, as well as business experience.


I can sell the keychains which house the QR codes, and I can provide this web service on a subscription basis. Costs have not yet been figured.