Sponsored Link •
|
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
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...
Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.
Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification. |
Sponsored Links
|