Why Boston ran out of Ballots in the Last Election

Last Friday, Professor David King presented the results of his review of the Boston Election Department at a meeting of the MIT Voting Technology Project. His work has been mentioned in the press, but this is the first time that David has been able to publicly comment on his recommendations.

There are number of interesting changes that the Boston Election Department will implement thanks to David’s input:

• The name of the department is changing to “The Department of Voter Mobilization”, which is an interesting way to emphasize its role.
• The organizational chart now looks reasonable, whereas before it was everyone reporting to one person.
• The technical means for data sharing will be improved, and training on sharing data will be improved.
• Funding will be increased significantly, given the department’s role in both running elections and the yearly census.

This is all fantastic stuff, and much credit should be given to the department and the mayor’s office for allowing this kind of review to happen and for taking the criticism into account. This is so uncommon in politics today that it’s almost shocking (even though I would prefer even more openness.)

But the really interesting issue, in my mind, is why did Boston run out of ballots? The core reason is surprisingly simple: the ballot was longer than usual, requiring two sheets instead of one. As a result, the secure precinct blank-ballot boxes were simply too thin to contain enough ballots. The election office realized this only shortly before the election, and set up vans to distribute extra ballots to the various precincts on an as-needed basis. But they set up the van routes poorly, and they didn’t have the phone capacity to handle warden cries for more ballots. As a result, the vans were ready, the ballots were ready, but they were delivered to precincts that didn’t need them, and some precincts that did need them ran out.

Sounds stupid, right?

But to any software engineer, this should not be surprising. Whenever one deploys software, it’s usually the little stupid issues that get in the way and snowball into gigantic messes. Permissions set up differently on the production server, a slightly different version of a library, a tiny difference in the network configuration, all causing some unforeseen behavior in the software that ends up in a massive crash and burn. In one of my first programming jobs, I upgraded a key piece of software the night before a big demo, which unfortunately introduced a small bug in the date() function, which led to a complete breakdown of a major feature we were demo’ing. Deployment of mission-critical operations, be they software or process, is unbelievably hard, because one can rarely predict all the crazy little issues that may crop up. And the hard part, of course, is that it’s practically impossible to stage a realistic mock election, whereas it’s usually reasonable to stage a mock software deployment (though, even then, not enough software engineers do it.)

So bigger secure ballot carriers have been ordered for Boston, and the ballot thickness problem is now solved. But there’s always another small-but-deadly issue around the corner. Thus, it’s not surprising that election officials are incredibly conservative when it comes to changing anything: they never get a chance to stage the changes properly! I’m glad that we get to see David’s report: the fact that the culprit was ballot thickness is a sign of an understandable operational failure, not of malicious intent.

(I wrote up my experience as a Boston Precinct Warden during that November 2006 election, both in a blog post and, in greater detail, in a written report I gave to David, which apparently made it into the detailed internal report to the Boston Department for Voter Mobilization. Woohoo!)