Summary
Some reflections, not on the current election, but on the process of voting (and the electronic tallies thereof) on this, the eve of our doing it again...
Advertisement
Tonight is the eve of yet another presidential election. This is hardly
the place for a discussion of the candidates, but it might be the place
for some thoughts on voting. Especially electronic or computerized voting,
which seems to be in the cross hairs this year.
In all of the discussions I've heard about voting procedures and the
computerized machines that will embody those procedures, there are two
questions that I haven't really heard discussed. Until they are, and
until we have some agreement on the answers to those questions, we
aren't going to go very far in getting a solution. This doesn't really
have to do with voting, it has much more to do with the way computer
system are designed.
The two questions that need answers, bluntly put, are
What errors are we trying to avoid by introducing computerized
voting systems; and
What margin of error is acceptable for the resulting system?
I ask the first of these because, in at least the discussions I've heard
on the topic, there seems to be a confusion in what the goal of the
system should be. One goal is to accurately count the votes of the
citizens, as quickly as possible. The other goal is to insure that there
is no fraud in the outcome of the voting. These are clearly different
goals. One can build a system that tries to insure that an accurate vote
is taken quickly that assumes that the poll workers are honest and can
deal with fraud. Or on can build a system that will help to detect
fraud, although it may slow down the counting of the vote. Building a
system that does both, however, is more than twice as hard as building a
system that does either. At least none of the systems I have seen
proposed does both.
Of course, it is well known that unless you have the goal of your system
well defined, it is very hard to design and build that system. Worse
still, when a system is designed for one goal, and then asked to meet a
different goal, the general result is a system that meets neither. So
without some agreement on the goal, electronic voting is going to be an
endless series of build, criticize, and rebuild.
My second question seems to get people even more uncomfortable when I
bring it up during discussions of electronic voting. So let me begin by
making a bold assertion: any mechanism for voting, being a human
artifact, has some margin of error. I remember being a counter
in a New England town meeting. This was a situation where there were
only about 150 voters. There were two counters, to insure accuracy. But
we never were sure that we always had things exactly right; all we could
know is that we agreed on our count (and sometimes that agreement came
via negotiation). As the number of voters scales up, the possibility of
error does, too. No mechanism will be perfect, and that's ok.
The problem comes when the margin of error is greater than the margin of
victory. We have had this happen, most famously during the last
presidential election in Florida. Many people were shocked when the
recounts kept changing who won and by how much. If there were a perfect
way of tallying votes, this would have been shocking. But if you realize
that there is a margin of error, all the recounts did was to show the
size of that margin. Sometimes the margin showed one candidate winning,
sometimes it showed the other. Count three times, get three answers.
It may be logically possible to invent a mechanism that has a margin of
error approximating zero. The smaller the margin, the better, but with
the number of people involved, the stress of the situation, and the
frequency of the phenomenon, this seems like an unreasonable
goal. Certainly reaching this goal, along with attaining the goal of
fast returns, is going to be very difficult and very expensive, given
that the error can occur with the voter, the system, or the reporting.
Of course, if we admit that there is a margin of error, we then need to
decide what to do if that margin of error is greater than the margin of
victory. The founding fathers allowed for this sort of thing (send it to
the House of Representatives), and there are other precedents (let the
Supremes decide). This does have a ring of an undemocratic process. But
it might be one that works...
It is interesting how difficult it is to design a software system to replace pieces of paper. I know someone who has a little coffee stand; when you buy your double decaf no whip extra hot latte, you put a stamp on your card. When the card is full, you get a free dring. I considered writing a program to replace that system. After a little thought, it became clear that it was not a small task.
Probably part of the problem comes from the analysis of the problem. We don't think about those two questions so much with regard to existing voting systems, but when we do when creating a new system.
The good thing is that the accuracy of the tally in a democratic vote is probably not really that important. The majority of the electorate is probably not qualified to make an intelligent choice anyway (I have evidence!). This especially so given the limited choices available and compounded by the fact that the vast majority (in the US) don't even consider more than two from all the available choices.
Hmm, how about just having all the candidates that get more than say 10% of the popular vote draw straws?
I, too, wish to tread carefully here. I don't need a political axe to grind to make add the following: This is a straight-forward V&V problem. Verification and Validation answer the two questions, "are we building the product right" and "are we building the right product". Both questions demand answers that have a basis in solid requirements gathering (which, hopefully, relate to Jim's design goals point).
"Local officials said UniLect Corp., the maker of the county's electronic voting system, told them that each storage unit could handle 10,500 votes, but the limit was actually 3,005 votes. ... Officials said 3,005 early votes were stored, but 4,530 were lost."
What requirements were in the system for error checking? What system requirements existed for training of election workers? What kind of developer says, "we won't bother checking for a full file system... if too many votes are cast, start throwing them on the floor"? Friends, this isn't rocket science; this is the kind of error checking (or lack thereof) we'd flunk a first year programming student for bungling.
The sanctity of the voting booth depends on the transparency of the voting process. Treating voting mechanisms like a "black box", with no visibility, no peer review, no external standards or criteria breeds this kind of failure. The problem with the current generation of voting machines isn't just that the boxes are bad; the problem is the processes that created them are bad.
Given the future of our country rides with every election, why isn't a voting machine considered a safety critical system? If we were to give the same care and thought to voting machines as are given to, say, avionics equipment, I'd have a lot more confidence in their use.
Electronic voting machines should, I think, be considered somewhat of an exception, and atypical example, of systems design. That's because they bring into play an important psychological aspect of software systems: It may be possible to design a system that reduces its margin of error to a number close to 0, but we may not want to have such a system in place.
To put it in a different way: Because the requirements of such systems must be approached from a context far wider than just the problem domain at hand, it might be so difficult to build a satisfactory system to meet those requirements that to not build a system at this time may be the preferrable option.
For intance, it may be possible to create identity systems that help ensure that only those qualified to vote cast a vote, and that fraud is minimized. That would require some sort of biometric identity database, and some other requirements that the government would have to impose on citizens to ensure that each voter is properly identified and that their voting eligibility is properly verified.
Citizens in many countries may not flinch at such a solution because, after all, that sounds like a logical solution. However, such a solution would go completely contrary to what I think is a core element in the psychological makeup of the American people: that such a big-brother database, and that even a national identity system, is too dangerous to be worth any benefit it may provide because such a system would merely place the possibility of fraud on a grander scale.
While the Founding Fathers could not have anticipated that dilemma, they surely understood democracy to be an imperfect game, its rules to be mastered only by a people willing to recognize, and live with, the possibility of error inherent in that system. They also understood, btw, that democracy was not the most important aspect of the American system, and they reserved more attention to those checks and balances that ensure each citizen's rights, be he part of the victorious majority or the defeated minority.
Regardless of the goals or implementation of a computer voting system, it should be done with open source software. Even if that software is developed by companies which are paid to develop it. The idea that these companies might allow some government employees to review the code is a red herring: the one real power of open source software is the fact that a large number of proficient and critical eyes can examine it.
It simply ought to be illegal to have any portion of the voting operation controlled by secret processes.
I wonder if there are (or have been) companies that receive all the paper ballots (without anyone else having tallied them), count them and return a list of the results, without disclosing how they got the results, or allowing anyone else to see how they do it (or to even see the original ballots). Seems like such a thing would be unthinkable, but throw compusters into the mix and people become more complacent. Maybe there is a little too much trust in the magic of technology?
> the one real power of > open source software is the fact that a large number of > proficient and critical eyes can examine it.
Even if the software is open-source, there is the practical difficulty of examining the processes the system uses. The problem is not so much in counting votes, but in determining who is eligible to vote, and what to do when people don't follow certain regulations about the election process. There is then a human decision involved, and that decision introduces a fudge factor, no matter how much trust we place in the computerized system.
Of course, that's just an example of user errors: a user who enters the wrong price for an inventory item, the customer who transfers the wrong amount of money from a bank account, etc. The difference is that many (not all) of these human errors can be rectified, i.e. a transaction can be rolled back. But, as Jim pointed out, one requirement in a voting system is quick results. You can't roll back the results of a presidential election because people erroneously pressed the wrong button - the timeliness of pressing that button is very significant. So when people compare a voting system to other business systems, the comparison doesn't go too far.
1. Bigger the state, more the electoral votes that go a candidates way. On this count do different states have varying tolerance levels, the more 'important' ones being less tolerant of errors?
2. Historically, a particular county has closer contests - does this make this county less tolerant of errors?
3.If a single system is used all across the nation - then would it have varying levels of errors.
4. what are these errors - a) when writing to memory cards, b) communication(i.e. network) errors c) COmponent Hardware-failure errors d) Software bugs e) Confusing interface? (as in 2000).
Previous Topic
