No Confidence Vote:

Why the Current Touch Screen Voting Fiasco Was Pretty Much Inevitable

By Robert X. Cringely

If you spend any time on the Internet in the U.S., it is almost impossible not to know about the scandal involving touch screen voting machines.  I mentioned it a few months ago, and my goal at that time was to goad the big newspapers into looking at the story, with the idea that if there was any truth to it, the New York Times and Washington Post ought to be on the story.  Well, now they are, especially the Times, which this week ran an op-ed piece by Paul Krugman that ought to make a lot of politicians very uncomfortable.  Depending on whom you read, either computerized voting is being used to help American voters or to hurt them.  The American Civil Liberties Union said in California that certain counties in the recent recall election were disenfranchised by not having touch screen voting, while other organizations suggest that touch screens were used to steal elections in Georgia.  I don't know about any of this, but I do know about Information Technology, so I suggest we look at this issue in a way that nobody else seems to be as an IT problem.

Voting is nothing more than gathering and validating data on a huge scale, which these days is almost entirely the province of IT.  And like many other really big IT projects, this touch screen voting thing came about as a knee-jerk reaction to some earlier problem, in this case the 2000 Florida election with its hanging chads and controversial outcome.  Punch card voting was too unreliable, it was decided, so we needed something more complex and expensive because the response to any IT problem is to spend more money making things more complex.

So the U.S. government threw $3.5 billion on the table to pay for modernizing voting throughout the land, which is to say making it more expensive and more complicated.  That's a lot of money and it attracted a lot of interest.  One company in particular, Diebold Systems, went so far as to buy a smaller company that made voting machines just to get into the market.  Diebold thought that being in the automated teller business was a good starting point for changing the way America votes.

You can read in many other places about the trials of Diebold as it attempted to build its touch screen voting system. I'm not here to write about FTP sites or whether voting machines can or can't be messed with over the Internet.  We're looking at this as an IT project, remember?  This isn't politics (at least not in this particular column) it's engineering.  And one thing engineers of great big IT systems know is that they are never on time, never on budget, and sometimes don't work at all.

Software development projects fail all the time, no matter what their size. The Standish Group, an IT-research firm in West Yarmouth, Mass., has been keeping track of this phenomenon since 1994, and the good news is that we are doing much better at completing projects than we used to. The bad news is that in 2000, only 28 percent of software projects could be classed as complete successes (meaning they were executed on time and on budget), while 23 percent failed outright (meaning that they were abandoned). Those numbers are improvements over a 16 percent success rate and a 31 percent failure rate when the first study was done in 1994.

I can't imagine too many business owners liking those odds, but the picture does get darker. If 28 percent of software projects were complete successes in 2000, then 72 percent were at least partial failures. And in software, even partial failure generally means getting absolutely nothing for your money.

According to the Standish Group, more than $275 billion will be spent on software development this year, covering about 250,000 projects. That means that if the recent success and failure percentages apply, $63 billion in development costs will go down the toilet in 2003 alone.

What does this have to do with voting machines?  It says that this whole idea of changing by 2004 the way every American votes was probably doomed from the beginning.  Whether political motivations were involved or not, the odds were always against this thing coming in on schedule or on budget.

Then why do we do it this way?  The "it" in this case doesn't mean just this voting project.  Why do we undertake these massive IT projects that almost inevitably fail?

The answer is simple because there is lots of money to be made whether the darned thing works or not, and not much of a penalty if it doesn't work. Two hundred and seventy-five billion is a lot of money to spend on software development, especially if 72 percent of that money will be either wasted completely or used to develop something that doesn't work intended.

Does that begin to sound like the current state of this voting fiasco?

So we were stupid to expect this thing to work as planned.  Except that as far as I can tell, there wasn't really a plan. Here's what I think happened.  This is, unfortunately, far too common in the IT world.  After the last presidential election, there was a government outcry for an electronic voting system.  Firms like Diebold who make ATMs, check out systems and kiosk systems said, "Hey, we can make a voting machine out of one of our products."  That was probably the total extent of thinking and requirements put together by the government agencies and the vendors.

In the case of this voting fiasco, there was a wonderful confluence of events.  There was a vague product requirement coming from an agency that doesn't really understand technology (the U.S. Congress), foisting a system on other government agencies that may not have asked for it.  There was a relatively small time frame for development and a lot of money.  Finally, the government did not allow for even the notion of failure.  By 2004, darn it, we'd all have touch screen voting.

Oh, and there are only three vendors, all of whom have precisely the same motivation (to make as much money as possible) and understanding (that Congress would buy its way out of technical trouble if it had to).  This gave the vendors every reason to put their third string people on the project because doing so would mean more profit, not less.

One definition of insanity is doing the same thing over and over again, somehow expecting a different outcome.  In this instance, the issue isn't whether Diebold and the other vendors were insane (they aren't), but whether the government is.

Now against this back of failure, I can't help but make one technical observation that I think has been missed by most of the other people covering this story.  One of the key issues in touch screen voting is the presence or absence of a so-called paper trail.  There doesn't seem to be any way in these systems to verify that the numbers coming out are the numbers that went in.  There is no print-out from the machine, no receipt given to the voter, no way of auditing the election at all.  This is what bugs the conspiracy theorists, that we just have to trust the voting machine developers folks whose actions strongly suggest that they haven't been worthy of our trust.

So who decided that these voting machines wouldn't create a paper trail and so couldn't be audited?  Did the U.S. Elections Commission or some other government agency specifically require that the machines NOT be auditable?  Or did the vendors come up with that wrinkle all by themselves?  The answer to this question is crucial, so crucial that I am eager for one of my readers to enlighten me.  If you know the answer for a fact, please get in touch.

Having the voting machines not be auditable seems to have been a bad move on somebody's part, whoever that somebody is.

Now here's the really interesting part.  Forgetting for a moment Diebold's voting machines, let's look at the other equipment they make.  Diebold makes a lot of ATM machines.  They make machines that sell tickets for trains and subways.  They make store checkout scanners, including self-service scanners.  They make machines that allow access to buildings for people with magnetic cards.  They make machines that use magnetic cards for payment in closed systems like university dining rooms.  All of these are machines that involve data input that results in a transaction, just like a voting machine.  But unlike a voting machine, every one of these other kinds of Diebold machines EVERY ONE creates a paper trail and can be audited.  Would Citibank have it any other way?  Would Home Depot?  Would the CIA?  Of course not.  These machines affect the livelihood of their owners.  If they can't be audited they can't be trusted.  If they can't be trusted they won't be used.

Now back to those voting machines.  If EVERY OTHER kind of machine you make includes an auditable paper trail, wouldn't it seem logical to include such a capability in the voting machines, too?  Given that what you are doing is adapting existing technology to a new purpose, wouldn't it be logical to carry over to voting machines this capability that is so important in every other kind of transaction device?

This confuses me.  I'd love to know who said to leave the feature out and why?

Next week: the answer.