Lessons from Iowa’s Caucus Debacle

Earlier this week, the state of Iowa held its caucuses to choose each political party’s nominee for November’s presidential election. Being the first state in each election cycle to do this, the electorate of Iowa has the attention of the nation; a candidate’s healthy or anemic showing in that state often foretells his or her success for the rest of the states’ primaries.

Electing public officials is a process that, even in an increasingly high-tech world, remains largely a paper-based operation. Electronic voting is still the wild west, with little regulation and no real standards for data storage or security. I’ll save for another time my commentary on the debate over paper versus electronic balloting, but suffice it to say that electronic voting is still very early in its evolutionary process.

What happened in Iowa?

During last Monday’s Democratic party caucus in Iowa, a crowded field of more than 10 candidates made their final push through the state as voters filed into their local caucuses to voice support for their candidates. As they always do, 24-hour news outlets filled the airwaves with speculation as they waited for the results to come in.

On the surface, things appeared as mostly normal. But this calm belied a rapidly approaching storm. For this election, Iowa Democrats purchased a relatively new app for tallying local precinct results and submitting them to the centralized database. However, some of the precinct chairs had trouble downloading the app before the caucus, and some of those that did found glitches in the app. It was reported that only a quarter of the precinct chairs had even installed the application.

On the night of the caucus, these factors coalesced into a very public disaster. There were widespread issues using the app, complicated by the fact that there was a different set of credentials to use on they day of the caucus than they had previously been using for testing. When precinct chairs tried the contingency plan of phoning in their manually-counted votes, they were met with long hold times, and one of them was even hung up on.

By the end of the night, not a single precinct had posted its voting results. A limited set of results was released in late afternoon on the following day, and as of the time of this writing, more than 48 hours later, the results are still incomplete. In a time when an entire nation’s votes for a presidential general election are tabulated within a matter of hours of the polls closing, it is inexcusable that a single state’s primary results are still listed as inconclusive after two full days.

What went wrong?

We don’t yet know the full story of everything that transpired on or leading up to the day of the caucus. But with what little has been publicly reported so far, there are a few things that are clear:

• The process to download and log into the app was challenging
• There was inconsistency in how the results were collected and sent, with some volunteer precinct chairs unable or unwilling to use the app
• The contingency plan to phone in the manually tabulated results did not work as intended
• The process repeated some of the same mistakes from the caucus four years prior

Some will likely blame a single cause for this meltdown, but I’d wager that an objective post-mortem would find that this was a failure on multiple levels. Having worked as a technologist for two decades, I have found that projects of this scope don’t jump the tracks due to single misstep; there are almost always systemic errors that come together to cause such an initiative to stall or outright fail.

What can we learn from this?

One does not have to be engaged in political schadenfreude to learn something from this failure. Regardless of any party leanings, those who build, buy, or support data architectures can find antipatterns in what happened in Iowa this week.

• Make it as simple as possible. If your users have go to through multiple download steps just to get to the app they need, many will opt out entirely. Know your audience and design the system with their abilities in mind.
• Make sure your users or customers are on board. If only 25% of your user base is even using the app or service, that’s a huge red flag that needs to be addressed before the big day.
• Training is mandatory. Especially in a case like this where the skill level of your user base is widely varied, you’ll need a solid plan for training as well as responsive support staff to handle questions or issues.
• Learn from past mistakes. If you are trying something that has been unsuccessfully tried before (even with a completely different team or organization), make sure you don’t get stuck in the same rut.
• Don’t rely on untested connectivity. If you’re relying on an unknown network – or even worse, a cellular connection – for connectivity, make sure you’re testing it before the show begins.
• Enterprise data collection requires enterprise devices. Asking users to run mission-critical apps on their personal computers or cell phones introduces unacceptable security and supportability risks.
• Test your contingency plans. That “In Case Of Emergency, Break Glass” box is useless if its contents haven’t been tested under realistic conditions.

Final Thoughts

I’m neither an advocate for nor an opponent of electronic voting systems. The data guy in me wants to automate all the things, while the pragmatist in me says that elections are too important and have too many complicating factors to simply toss out the old paper way of doing things.

Regardless of one’s take on this topic, I’m certain we can all agree that this episode presents a great opportunity for learning about how not to approach enterprise data applications.