It was a hot (and entirely hypothetical) August Monday when we were approached by a county in Oregon to give them an estimate on supplementing their absentee voting process with an online voting system. During initial discussions, we were told that registered voters receive a voting package in the mail with their login information. We were given the following conditions that outlined the county’s objectives:
- Augmenting the absentee ballot process currently in place to allow online submissions.
- The application should only allow access during a specific time period.
- Voters should be able to log into the application (with information that was mailed to them) and fill out an online version of the absentee ballot.
- Once satisfied, a user can click a button to submit the ballot.
The situation described in this article is fictional; the bullets above gave us a small set of starting requirements, similar to what we often receive from new clients.
The goal of this article is to illustrate how we might go about developing an application that could be used by a county to administer its voting process online. There are many unaddressed real-world issues outside the scope of this article that remain as barriers to implementing a secure online voting system, but there are current examples of similar systems in existence as well.
We set up meetings with the client and started what we call a foundation phase. This time in the process is designed to flesh out all the details and potential problems with the project. In these meetings, we document each step in the application, writing out the application flow and design functionality in a way the stakeholders and the developers can agree upon. We create use cases and screenshots, and will often create flows that mimic clicking through the application to be sure we haven’t missed anything. This leaves us with a document explaining what’s in as well as what’s out of the application.
The next step in the development process was to build a set of tasks that can be used for estimating the project’s timeline and budget. Based on the document we created in the foundation phase, we divide the work into digestible chunks. There’s a lot of debate about how to estimate tasks. Some developers work faster than others. Some people are better at estimating than others. We often use story points, which are an arbitrary measure that is used to describe how hard a task appears to be relative to other tasks. This allows us to measure the hardness of a task relative to another task without being bound to a specific number of hours. Over time, you can measure how many story points are being completed by a particular team, and then you can forecast when the project will be completed.
In the case of the hypothetical Oregon county, we put together a developer team with the following roles:
- A project manager
- An architect to plan and build the underlying application structure
- Two back end developers that use the skeleton built by the architect to code API endpoints
- A security expert working with the architect and developers to ensure modern security best practices
- Two front end developers to build the graphic interfaces for phones and computers that communicate with the APIs
Cone of Uncertainty
At this point in the project, we knew a lot more than we did at the start, but even being diligent about our foundation and task estimation, there is always “dark information” hiding out there, requirements hidden behind more obvious choices and within undefined scope. The cone of uncertainty can help illustrate this issue.
We’ve defined the project scope and created a set of tasks to complete the project. We’ve scheduled our first set of work and development begins. We like to use an agile/iterative development process, which includes frequent scrums to keep team members informed about the process. We use sprints, which define a set period of time within which specific tasks will be completed and made ready for review. This is an iterative process, as we complete sprints, incomplete work rolls forward, new sprints are created with new tasks, and the whole thing starts over. The bucket of tasks to complete gets smaller and smaller, and the more work that gets completed, the easier it becomes to tighten the estimates for final completion.
Depending on the size of the project and the team, the pace of development, and the efficiency of the team, testable areas of the project can emerge at different rates. On a small project, everything might be ready to test at once. On larger projects, I see it more like a skeleton that’s having its body built around it like the transparent pages of nerves, muscle, and veins in my old science book. As these testable areas of the project are exposed, they can be put in the hands of the client, internal testers, or automated testing applications to confirm that the code is functioning as expected. Many kinds of tests can be run, and I won’t go into depth here, but I’ll say that there are tests for pretty much everything you can imagine. As bugs are found, they are entered as new tasks and added back into the development workflow to be added to upcoming sprints. Again, this entire process — identify, develop, test — is repeated until there are no tasks left to develop and no items left to be tested.
In this case, it would be important to test our application in many ways. We must be sure that our users can vote in their preferred language, that the system can handle a large percentage of the population voting simultaneously, that votes are counted properly, and so on.
Finally, we arrive at deployment. The application is tested and ready to be set loose on the public. In this case, a cloud platform like Amazon Web Services could be used to allow the application to be scaled to accommodate high demand situations.
Creating a process for submitting absentee ballots has been attempted before; at least once, such an effort was canceled due to security concerns. It’s important to keep in mind that any process is only as secure as its weakest point, but this must be weighed against the voice of those that do not have access. How many more would vote if they had more access? How many more if the process was provably secure? I look forward to the debate as technology advances, and it becomes easier for voices to be heard.
You May Also Like
- Blog Post 1 – Why Can’t We Vote Online?
- Blog Post 2 – Would You Vote Online?
- Blog Post 3 – Developing an Online Voting App
Further Reading
- Hack Brief: As FBI Warns Election Sites Got Hacked, All Eyes Are On Russia – wired.com
- FairVote – Research – Voter Turnout – fairvote.org
- Why can’t Americans vote online? – engadget.com
- For Every 10 U.S. Adults, Six Vote and Four Don’t. What Separates Them? – nytimes.com
- Fusion.Net – January 2015 Survey of Millennials – fusion.net
- Poll: Millennials eager for online voting – thehill.com
- National Conference of State Legislatures – Electronic Transmission of Ballots – ncsl.org
- Hacking the Election: Myths & Realities – computerworld.com
