Technical disaster meets political disaster this week in Iowa. It looks awful for the Democrats and we still, as of this writing, don’t know who won.
Mistakes of people and mistakes of process are largely responsible for the failure of what should be a relatively simple technical task.
There are four key areas of problems that have been mentioned in the media:
- Vendor selection processes that favor acquaintances
- Poor choices of technical structure (app vs web)
- Lack of proper load testing
- Improper design
Solving load problems with apps and websites can be tricky. Still, there are well known, common sense approaches to load testing.
Technical problems are always easier to solve than human problems. And it’s political problems within the democratic party that drive how software vendors are chosen that are at fault here. (Hint: the selection process is not entirely merit-based). Both human and technical are likely to have contributed to what CNBC calls “One of the most stunning tech failures ever”
Vendor selection processes that favor friends
Technology partners used by campaigns and political committees are selected heavily based on the personal connections of the political insiders, people in the narrow world of campaign managers and their preferred contractors.
It’s no wonder that the team that the Iowa democrats have selected to deliver technology for the caucuses has ties to the Clinton team. Who vetted this technology vendor and how well?
The app vendor is Shadow Inc and it appears that the company’s CTO, Krista Davis, has excellent experience. She moved from engineering at Google to working on campaign and political tech, and founded Shadow after working on tech for the Clinton campaign.
Originally, the technology business was Groundbase — a campaign organizing software. It does not appear to have been built initially as a voting system. Still, Shadow Inc somehow got the Iowa caucus job. They received a contract to deliver a custom mobile app.
TechCrunch reports that the cost was $63,000, paid in two installments. This is a minimal cost to deliver an app, especially if it needs to support both Android and iOS. One hopes that some technical groundwork was already in place and the apps only needed to be customized, but it’s apparent at this point that whatever work was done, it was clearly not enough.
Poor choice of technical structure
At this low cost, the choice to create an app that users have to install on their different devices was the wrong choice. The functionality of submitting vote results securely can be developed through a web browser interface at a lower cost.
It is hard to believe that, as Iowa democratic party statements keep repeating that “the underlying data” is not impacted. If this was the case, it could easily have been retrieved the same evening, in spite of any issues with the reporting system.
Lack of proper load testing
A proper load testing scenario for all the caucus locations should have been developed and simulated prior to the caucuses. This should have been thoroughly tested with both the central counting offices and at a majority of the polling locations.
Vox reports that the app was only meant for precinct captains, so the overall load (assuming every precinct captain used the app, and they did not have to) is under 2000 users. It’s a really minimal load.
Here are the steps we use at MeetingPulse when designing a load test.
- Speak with the customer about the expected pattern of incoming votes
- Build software agents (bots) that simulate this voting pattern as quickly as possible
- Spin up infrastructure to simulate agents coming in from multiple online locations
- Have the agents submit votes and observe the system
- Make changes and adjustment as necessary to ensure results are not compromised
This is a fairly common sense and standard process, and in such a high profile scenario, we would recommend that any software vendor follow it.
Improper design
Not paying attention to the design of the software is another common problem: there were early reports that the interface was confusing folks at the caucus locations.
Improper design can cause both data problems and further load issues, as users reset, reload the page, submit data multiple times, and look for work around to figure out what to do with poor and confusing software. Fast company reports on the design problems and lack of testing with users.
Conclusion
For a robust and secure voting system with custom solutions, reach out to us at MeetingPulse. We guarantee we’ll design it with your users in mind, test it properly, and train the users ahead of time.
Success! Or your money back.
