(Note: Previously titled Database Theory, Positive Mark Voting and the FL-13 Election but changed at the suggestion of a commenter)
The mess in Florida-13 has received a fair amount of digital ink here at dKos. While the outcome is not clear, it's becoming pretty obvious that one of the main problems in the election was the layout of the ballot on the new electronic voting machines. The ballot layout in one heavily Democratic county made it hard to find, and easy to miss, the election for US House member:
http://images.dailykos.com/...
I've worked in database design and programming for just under 20 years and it's clear to me that, while good software design is hard (as the President might say) any junior programmer should have been able to avoid the problem seen in Florida. Follow over the jump for a consideration of the single standard that would have made the difference. . .
First, let me say what issues I'm not going to address in this diary:
- Paper vs. electronic. I'm only going to talk about the design of electronic voting machines. For reasons that should be clear by the end of the diary, I think electronic machines are actually a good idea as compared to a pure paper system.
- Verifiability. Only an idiot would design a software system that could not verify its function and results.
- Paper trail. Given that I'm not interested in any system that is not verifiable I leave it to the reader as an excercise whether or not verifiability requires a paper receipt. By which I mean I haven't thought about the question a great deal.
- How this particular election should be resolved.
These questions are not relevant to what I want to talk about -- the single most important standard that should apply to any electronic voting machine. I call it Postive Mark voting.
Database Theory
Consider the following two database records:
Name: Joe Smith
SSN: 123-45-6789
DOB: 7/15/69
Name: Theodore Papandreulykodopolos
SSN:
DOB: 9/22/74
Assume I'm a provider of some service which is only available to US citizens. I can provide that service to Mr. Smith. But is Mr. Papandreulykodopolos eligible?
The answer is, I don't know. There are at least two possible conditions represented by that blank social security number:
- Mr. Papandreulykodopolos does not have a social security number.
- Mr. Papandreulykodopolos's social security status is unknown -- he might have social security number, he might not.
(There are other possibilities such as "refused to state" but we'll ignore them for this example). Given the fact that I can't distinguish between the cases, chances are I will refuse the service to Mr. Papandreulykodopolos especially if, as is beginning to happen in some states, I could be sent to jail for providing it.
A data field with no value in it is said to contain the special value NULL. The value NULL has no meaning other than "the value of this field, or whether a value even exists, is not known". What this means is that a database record like this:
FirstName: Roger
MiddleName:
LastName: Dodger
represents a record not for someone with no middle name, but rather a record for someone whose middle name status is unknown. To represent a case in which you know the person has no middle name you would have to invent a special value "NMN" to go in the MiddleName field or use the dreaded zero-length string (which looks like, but is different from, a NULL). In the "real world" most databases don't take this too far -- they permit a NULL value to mean "blank" in fields that commonly have no value.
But this has a direct and important implication for electrontic voting. Consider the following ballot:
US Senator: Bill Nelson
US House:
Governor & Lt. Governor: Jim Davis & Beryl Jones
The question is -- did the voter abstain in the US House race? Or did they simply fail to notice the race? There's no way of knowing from looking at the data.
What's needed is an additional choice -- it could be called "Abstain", "No Vote Cast", "None of the Above", or whatever. If the voter is then required to mark every race before they are allowed to leave the ballot page there is no possible ambiguity over the results. If the voter really doesn't want to select either of the candidates they would have to mark "No Vote Cast". At then end of the vote counting, if one county had significantly more occurences of "No Vote Cast" than another then that would be the accepted result of the election (assuming the machines had passed their verification tests).
I try to be an understanding guy. There are a lot of hard questions to answer about electronic voting machine design, many of which are either not obvious questions, or not appear deceptively easy to answer. But I have to say that it's unlikely that I would have worked on this project for more than a few hours without asking "Hey, how do we tell the difference between an abstention and a missed race?"
Therefore, I propose that it be a requirement that for any ballot to be valid there must be a positive mark on all races on the ballot. The voter must be provided with an option on each race for abstention. NULL values are not permitted. This simple change will not only eliminate the question of undervotes on electronic machines but significantly reduce the scope of influencing elections through ballot design, whether intentional or unintentional.