I would have posted this as a comment to Kid Oakland's
excellent entry, but 500+ comments was already a bit much.
I agree with Kid, but for a different reason. It's becoming clear to me that the problems with voting machines have little to do with actual fraud and a lot to do with sheer incompetence on the part of the computer programmers. I was a professional programmer for over a decade, including 3 years as a software engineer for IBM, and I have a graduate degree in Computer Science, so I have some idea of what I'm talking about.
Here's the story that tipped me off: Broward Machines Count Backwards. The story describes a problem in the software from ES&S: once a vote count goes over about 32,000, it starts going down. This actually happened in Broward County, Florida when the elections board was processing absentee ballots. The same software is used in Miami-Dade.
Is this evidence of tampering with Democratic counties? Alas, no. It's evidence of sheer incompetence at ES&S. I explain after the break.
The problem with the software is obvious to any computer scientist: the programmers used only 16 bits to represent integers. This is similar to the Y2K problem, where only two digits were used to represent a year. 16 bits can represent a number from -32,768 to 32,767 if you allow negative numbers. This is because every bit doubles the number of different numbers you can represent. (Zero counts as a positive number, which is why the positive range is one lower than the negative range.) So 1 bit can represent 2 numbers, 2 bits can represent 4 numbers, and so on. If you try to go over the maximum value, the number will "roll over" to a negative number because of the way that numbers are stored in the computer. (This method of storing numbers is called
two's complement if you want to research it yourself.) Once that happens, all the math from that point on will be wrong. The fact that the count only goes up to 32,000 successfully is a dead giveaway.
This is pure programming incompetence. Any modern programming language can use longer integers, although 16 bits are the default in languages like Java and C. Any competent programmer would have allowed for the possibility that there might be more than 32,768 votes somewhere. There is no practical reason not to use bigger integers and absolutely no excuse once ES&S was notified of the problem in 2002.
The programmers used the default, and apparently didn't understand how to solve the problem. No competent programmer would make this mistake in production code; this is an amateur mistake. And what's worse is that this mistake is only exposed through use in a densely populated county.
After this, it seems likely to me that the reason there's a correlation between Democratic precincts and voting machine problems is because the most densely populated precincts tend to go Democratic, and the higher populations will also push the limits of the software created by inept programmers. In other words, there's no conspiracy, just stupidity interacting with Democratic demographics in an unfortunate way.
I have a lot of experience with inept programmers, and this seems completely consistent with a lot of other software problems I've seen. This doesn't excuse ES&S (or any other software manufacturer) in any way: we rely on this software to enforce democracy, and it should be flawless. They also charge hundreds of thousands of dollars for it.
Rip-off? Yes. Republican cronyism shielding incompetence? Probably. Conspiracy to commit voter fraud? Probably not.