Having just recently released a new voting module for our platform, you can imagine we were quite surprised and shocked to see that the app for the Iowa Caucus had such problems. Could mobile apps be the wrong tool to use for elections? We obviously spent quite a bit of time digging further to see what happened. It would appear some very basic development steps were shortcutted. 

14 Oranges Roman Colosseum
Photo by David Köhler on Unsplash

Rome Wasn’t Built in One Day

What is true for Rome is also true for apps or any software applications for that matter. From all reports, it would appear that they didn’t allocate enough time (2 months?) to properly develop the app. Unless you are using a rapid application framework like Info Grove, apps generally take a lot longer to develop. The requirements phase alone could easily take 1 to 2 months. On average, custom apps take from 3 to 4 months for simple apps, 5 to 6 months for medium ones, and close to 12 months (or longer) for elaborate ones. The Caucus app would fall somewhere in the last 2 buckets. There is no rushing art. Well you can try but don’t expect good results. This YouTube video describes it very well:

Testing Step 

Call it testing, quality assurance, quality control, verification, or whatever name suits you, this step is always crucial to successfully deploying any piece of software. You can have an exceptional development team but without testing, the app will still have issues. It would appear that in the case of the Iowa Caucus, testing was very rushed and limited. 

There are many forms of testing (regression, sanity, automated, manual, so on) and the type that you use depends on the type of software you are deploying and also the impact the software can have. If you deploy a new piece of software on a single piece of hardware inside your facility, you won’t test the same way as if you are deploying a piece of software running on numerous devices which are outside of your control. The general rule of thumb is that for publicly available mobile apps, any one hour of development should be matched with one hour of testing as there are so many variations to test. For example, at our company, just for Apple devices alone we target deployment on 15 different types of phones (iPhone 6, 7, 8, X, 11, so on) on 3 different operating systems (11, 12, 13). On Android, the list is even longer as there are more phone vendors and types and also more operating system versions out in the wild. You can quickly realize that our test matrix is quite large. Unfortunately, it means it takes a long time to test. There is no way to avoid that. 

14 Oranges Vancouver Olympic Stadium Picture
Photo by me

Moreover, in events which are one and done with no change for recovery, you need to have a trial run or multiple ones prior to your final deployment. Our office happens to be a short distance away from where the Vancouver Olympic Oval is located and I recall that a year before the Olympics happened, they ran a major event to iron out any issues prior to the Olympics the year later. From our research, it doesn’t sound like any trials were done prior to the day. So when they found critical bugs, they didn’t have time to remedy them. 

Deployment Step

Another critical mistake is that the app was deployed using a framework called TestFlight. TestFlight allows developers to deploy apps outside of the app store and is useful to ensure apps are properly tested prior to deployment. That being said, the tool itself is designed by developers for developers and is not intended for general audiences; hence the name TestFlight. There are additional sign ins and invitation hurdles that must be completed prior to the apps being installed on the end user’s device. TestFlight would have been ok (although still questionable) for a trial run before the event or for an internal trial run at the company with perhaps a few outsiders. Beyond that, TestFlight should not be used. The Apple App Store and Google Plays have been in use for over 10 years now and people are quite comfortable using them. If it ain’t broke….

2016 Caucus Success with App

The 2016 Iowa Caucus used an app and that app was entirely successful. So successful that no one had ever heard about it (I believe that’s how Steve Jobs viewed technology). It just worked. Why they didn’t decide to use the technology again is a bit mind boggling.

Takeaways

I can somewhat understand why the Democratic party tried to deploy their own system. That being said, they really showed their inexperience with software development. Hindsight is always 20/20 but if you don’t have experience yourself, you best make sure that your development company has loads of experience so they can walk you through the process without problems. At our company, our team has well over 10 years of deploying apps and systems for some of the largest companies in the world (AT&T, BT, Cisco, Google) and every day we rely on that experience to ensure our projects are successful. 

With that said using a mobile app to conduct an election is still a viable option; however, just like with any piece of technology, it takes time to develop, test, and deploy. Even with our platform, for something of that exposure and importance, we would have made sure to take the necessary steps (enough time and a few trial runs) to ensure a successful event. You may not get a physical sticker, just an electronic one. 🙂

Mobile Apps for Elections – Understanding the Iowa Caucus App Failure