Getting your Trinity Audio player ready...

A simple definition of technology follows: the application of resources to achieve a goal. Often, the goal is a scientific endeavor, other times, it’s an efficiency objective, and let’s not forget a more obvious desire: solve a problem.

We live in a world littered with fascinating technology, ripe with seemingly constant change. If you take a few moments and ponder the major changes that have occurred in your life over the past few years, it’s likely that technology can be found among those events.

As a technologist, I will testify that technology is often imperfect. In fact, I worked in design for many years and the process of developing a new “computer” technology isn’t immaculate. I’m certain you’re familiar with the old saying, “you don’t want to see how the sausage is made”.

Technology development can follow the scientific method. Careful review, testing and analysis are the hallmarks of pragmatic development. However, nowadays, the desire to reach a goal, such as a new app, frequently requires abandoning rigorous testing. As a result, poorly designed software has become a normal for many of us.

We have become the testers, the evaluators, the frustrated audience for the rapid development of new software technologies. If enough of us complain and allow error logs to be whisked away, patches will arrive. Well, maybe patches will arrive.

Are there bad consequences of these approaches?

No doubt. Crashed apps are common, frustrated users are normal, and technologists fear moving away from stable software platforms.

Just this week, we were reminded of the real-world consequences of poor software development. The Iowa Democratic caucus was Monday night. It’s election year, 2020.

What does that mean? An app of course.

As the nation held its breath and waited with anticipation of the results from a crowded Democratic field, the new technology didn’t fare well.

Last month, the Iowa Democratic Party announced that it planned to use a mobile app to report precinct results. Despite requests by many, the Party refused to reveal much about the app. Independent security companies asked to review the app’s source code (the underlying instructions that constitute the app), those requests were denied. Some sought the testing process and those results; denied. Who developed the app? No comment.

According to the Wall Street Journal, elected officials asked for details about the app; those were met with the same refusal from the Democratic Party.

In the aftermath, we know what happened, at least we made observations and have notions of what happened.

The Iowa precinct chairs could not get the app to work properly. It crashed repeatedly. The app was built hastily, and testing was woefully inadequate.

What are some lessons learned from the Iowa Democratic app debacle?

As a starting point, let’s appreciate the importance of an election. There are few things more personal and important than one’s right to cast a vote. In doing so, we place our confidences in the systems and people who manage the technologies that facilitate our desire to voice our choice. The process of voting should be transparent and devoid of obstacles.

Based on the responses to inquiry before the Iowa caucus and the aftermath of the event, one thing is certain, the notion of rapid software design failed.

It’s important to state that the app did not cast votes. Rather, it was designed to deliver quickly the results of precinct votes to the state party. So, based on our basic definition of technology, it appears that the problem that was being addressed was expediency: deliver the results quickly. After all, all eyes were on Iowa – who had the time for slow results reporting. We want what we want right now.

If you’re in the business of running an election, transparency of your technology is essential.

Whether you’re using pencils and paper ballots or computer-based voting machines, allowing inspection, review of the technology and explaining to the voters what’s being used builds voter confidence. If I asked for information on the pencils and paper ballots and the response is “you’ll see, don’t worry about it.” I’m instantly worried.

So what are you to do?

First, explain what’s going on. Mount an open campaign about the technology and explain the purposes and reasons for the approach.

Next, allow, require independent inspections. Consider the value of positive validation of your technology from someone not directly involved in the process.

Test, test, test. Inadequate testing of software is irresponsible, especially given the purpose behind an app assigned to a voting process. Proper, rigorous testing will reveal deficiencies and allow for mitigation efforts – hoping for success and accepting likely failures as part of the process is disingenuous.

Lastly, provide adequate resources for success. Technical support resources should be highly available. Planned contingency efforts are a must. And, without a doubt, realistic time for all of the above is mandatory. Reports suggest that the Iowa Democratic app process was executed within two months. That is a tight timeline.

Conspiracy theories are running wild in the aftermath of the caucus. Russians are a favorite, the app developer, Shadow, Inc. has been beaten up – but, in reality, the explanation is far simpler.

Rushed software and unrealistic expectations gave way to an unfortunate experience.

The bottom-line? Technology development should take into account the intended use for the enhancement and develop accordingly. For voting technology, the technology must be accurate and open.

Trust in our election processes is essential. Failed technology is always disappointing, but, in this case, the failure eroded confidence in existing voter technologies and brings their design into question.

Be safe.