Moron voting machines

Holy cow! as Harry Carey used to say. My last post – about voting machines (“A post-election rant,”Advice Line, 11/8/2006), that asked how it’s possible that such a simple problem has been turned into such a collosal fiasco – led to more response than anything else I’ve written here, with the possible exception of the time I brought up birthday parties and Jehovah’s Witnesses (“Handling an employee who refuses to celebrate,” Advice Line, 1/4/2006, and please … no more on that one!)

To those who disagreed, complaining that I oversimplified a problem that really is complex, I have three things to say:

• I’m completely unencumbered by facts, and plan to keep it that way. That’s why it’s called a rant, and not a well-reasoned critique of the situation. Hey, sometimes a guy just has to have fun, and what can be more fun than criticizing the hard work of people you don’t know and will never meet? (Please – don’t post any comments in response to that question either. I have to filter out enough spam comments as it is.)

• Scope creep: I bet that a big reason for the unwarranted complexity is that we’re asking these systems to do more than record and tally votes – probably, some well-intentioned system designer or sponsor figured out that since we’re going through the trouble, we might as well ask the system to keep track of voters, their registrations, where they should vote, whether they already voted someplace else, what the exit polls said, traffic conditions, and a bunch of other useful things to do that have nothing to do with recording and tallying votes. Put all that stuff in future releases and the problem becomes much more manageable.

• “Simple problem” is a relative term. I’m well aware that in IT, “simple” means pretty durned hard, “difficult” means “if we make quite a few design compromises we might deliver this before we all retire,” and “hard” means “finishing this is what purgatory is for.” Unencumbered by the facts as I am, I actually am pretty confident that the main design challenges for a voting system fall into three categories: scaling (ideally, there are a lot of voters to tally), exceptions (for example, one commenter pointed out that some polling places handle multiple precincts, and that different geographic classification systems – for example, counties, cities/townships, and zipcodes – don’t always fit together nicely), and security.

The solution to the first is divide and conquer – ignore the everything-in-on-big-central-server crowd and distribute the load. The solution to the second is to ignore the problem. Yes, that’s right, ignore it. The exceptions will apply to a small percentage of precincts. Let them figure it out locally. They’ll either come up with clever workarounds, or they’ll handle it by giving voters absentee ballots in the precinct. Every good system designer knows when it’s time to sweep all of the remaining exceptions together and handle them with a couple of comment fields.

Which gets us to security. The solution to this is to stop trying for perfection, and instead be happy with good enough – in this case, the prevention of large-scale fraud. There is no way to prevent fraud at the individual polling place. The old Daley voting machine (of the political, not technical, variety) demonstrated this: Daley had precinct workers accompany voters into the booth to help them make sure they voted for the right candidates.

Set up a system that requires on-site presence for fraud and fraud won’t scale enough to be much of a problem. Add a simple audit trail (I’m far from the first to suggest this) and the solution really is good enough.

For all of those who suggested that mark-sense paper ballots will do the trick just fine … they probably will. They also chop down an awful lot of trees.

– Bob