What can we learn from the Iowa Caucus mess?

Iowa you an apology

At the time of publication, we're still waiting on final results from the Iowa Democratic Caucus. Results that should have been known on the night are now stretching into a third day. And why? It's all because of an app.

With the stakes so high, you'd think a $63,000 app  developed by a prestigious software company would be up to the task. So what went wrong? And what lessons can you learn for developing your app?

What happened in the Iowa caucuses?

On the evening of Monday 3rd February 2020 local members gathered across the State of Iowa to register their preferred candidates.

Shortly after the Caucus votes were completed, on that very same evening, the Iowa Democratic Party (IDP) was hoping to release the results via their newly developed app. But the results were not pushed through, users were left staring at a screen endlessly pending results.

Out of frustration users turned to the phone. The unexpected congestion forced everyone to wait on hold for over an hour. The call center was understaffed and unprepared for such a high demand, possibly because the IDP was confident in the successful operation of their new app.

In the midst of all this, and swayed by incomplete data from an internal memo , Pete Buttigieg raised eyebrows by declaring victory .

“So, we don’t know all the results,” Buttigieg said. “But, we know, by the time it is all said and done, Iowa, you have shocked the nation. Because, by all indications, we are going on to New Hampshire victorious.”

As it became clear that the app wasn't going to deliver official results to back up Buttigieg's claim any time soon, he was forced to walk back his remarks , and claim he was merely referring to his campaign overperforming expectations.

Even though the app had obviously failed to perform as expected, the Iowa Democratic Party still released a statement  on Monday saying that the app did not crash and that it was not hacked.

All in all, it was a messy process to kick off the primary season. But amidst the mess are some important lessons for anyone developing an app.

What was the app actually supposed to do?

It's important to understand that caucuses function differently to conventional elections. Rather than casting votes into a ballot box, support is demonstrated by physically standing in an area representing your choice of candidate.

This doesn't occur in a single location. Iowa's caucus process took place in rec centers, churches, gyms and other meeting places across the state.

The app was intended as an innovative upgrade to the ancient system of standing on a stool and counting the heads in each corner, then phoning in results to the state party. Organizers could now send numbers from their precinct by pushing a few buttons on an app, which should have led to a lightning fast final result.

Why the app crashed

There are a few reasons.

Firstly, the precinct chiefs were downloading and installing the app on the night of the caucuses. This resulted in a tremendous amount of processing strain. Some users were downloading and setting up the app at the same time as others were rushing through its functions.

Secondly, the app was not tested properly. The developers failed to account for the manic activity of its users and therefore didn't test the app in an environment accurately reflecting its users. Rather than being released through an app store or sideloaded with an Enterprise certificate, it was pushed to users as a beta test.

University of Iowa computer science professor Doug Jones, spoke to NPR  about the app's deficient testing.

"It appears in this case that the app was never really tested in a manner which came close to approximating the real mess of an election," Doug said.

But the app actually didn't crash. Rather, the stream of data delivery was congested, and when it did finally did come through, it was only showing partial information.

Thirdly, there was a problem with the app's software. Troy Price, chairman of the Democratic Party said that t  the app itself was sound, there was just a problem with its report coding.

So in summary, we have an app that wasn't used properly, wasn't tested properly and wasn't built properly.

If these issues were picked up by the developers  before shipping the app, all of this embarrassment could have been avoided.

And now for some hard hitting lessons.

What can we learn from the Iowa caucus disaster

Lesson #1: E2E Test your apps

All three of the major problems with Iowa's voting app could have been avoided with proper end-to-end testing.

To see why, take at look at the first stage of a typical E2E test planning process:

The first stage is requirements gathering. If the developers created accurate user personas , they would have expected the chaotic behavior of users and created appropriate test environments to account for it.

The final stage of the E2E testing is user testing. If the software developers of the IDP app were accurately predicted use behavior they would have asked a pool of test users to replicate it in a controlled environment and collected all test user feedback.

Having a lean business setup  helps development teams make quick and efficient modification to such user feedback.

Now let's take a look at a typical E2E test. E2E tests occur in two dimensions simultaneously, both vertically and horizontally.

The horizontal axis represents a particular user workflow. In an ecommerce store  example, the user workflow can be broken down into 4 stages

1. Product search

2. Add to cart 

3. Customer verification 

4. Purchase

The vertical axis represents each individual tech stack associated with each of the horizontal stages, this includes all 3rd party integrations.

In our simplified illustration above, the UI layer, the database layer and the 3rd party integration layer are activated throughout the entire horizontal workflow. So in E2E testing the individual performance of each of these layers is tested as the workflow progresses horizontally.

An app needs to pass both vertical and horizontal E2E testing in order to be cleared for shipping.

If the Iowa Democratic Party had their app properly E2E tested, the coding error that resulted in the incomplete delivery of poll results would have been isolated, identified and rectified.

Lesson #2: Educate your users

The users of the Iowa Democratic party app did not come prepared. If they had installed and set up the app prior to attending the caucuses there wouldn't have been such a high data demand on the night, which could have potentially prevented the faulty coding from making a significant impact.

Instead, the developers should have educated their users with laser-targeted marketing  campaigns to encourage them to download and install the app preemptively.

Once installed, the app developers could have sent through push notifications to educate their users on the reporting process to prevent them from stressfully trying to figure it out on the night.

Lesson #3: Expensive doesn't always mean better

When searching for the perfect app developer, it's common to assume that the most expensive vendors are the most talented. But the Iowa caucus blunder demonstrated that even the most outwardly prestigious firms are prone to infant developer errors.

Freelance mobile app developers are much cheaper than development firms and just as capable if not moreso.

Freelance Mobile App Development Experts

Technource Pvt Ltd

@SRajpurohit

12 USD / hour

4.8

(461 reviews)

PHP

Java

JavaScript

Python

.NET

Visit profile

KESHAV INFOTECH

@KESHAVINFOTECH

8 USD / hour

4.9

(1281 reviews)

PHP

C Programming

JavaScript

Website Design

Graphic Design

Visit profile

Om Infowave

@ominfowave

15 USD / hour

5.0

(285 reviews)

PHP

Java

JavaScript

XML

Website Design

Visit profile

Surendra P.

@gkws

25 USD / hour

4.9

(418 reviews)

PHP

ASP

C Programming

Java

JavaScript

Visit profile

Lesson #4: Use the right software development lifecycle model

Even though the real world is an unpredictable place for all released software, shipping bugs is unacceptable.

All software developers should follow an efficient software development life cycle model , such as the V-shaped model, to ensure rigorous testing occurs along every point of the development journey.

Lesson #5: Create helpful error messages

No matter how rigorous you are, your app is likely to run into an issue at some point. It could be on the user's side, it could be a problem with your servers or it could just be an unfortunately overlooked bug. Just remember: to err is human, to offer a vague error message is a jerk move.

That was one of the issues facing app users in Iowa. Motherboard reported that some users were met with a puzzling error screen upon trying to log into the app. The error message read, in part, "There could be a misconfiguration in the system or a service outage." 

See the issue there? Those are two very different problems. A service outage could be temporary and quickly rectified. A misconfiguration in the system could be fatal in the case of an app like the one the IDP was relying on.

Make sure your error messages explain in plain English what the problem is, and when and how it could be rectified. If it's user error, explain to the user what they did and what they should have done instead. If it's a server error, reassure the user that it's a temporary issue that's usually fixed quickly. Whatever you do, don't present them with an obtuse message that raises more questions than it answers.

Final thoughts

Mistakes happen and thankfully most of them time they don't occur as publicly as the Iowa Democratic party debacle.

Whether you're a developer or your business needs some software built, with all the right precautions place you can prevent your app from going Iowa-shaped.