Find Jobs
Hire Freelancers
Поспілкуйтеся в чаті з Авою – вашим бізнес-консультантом зі ШІ
Аватарка користувача
Привіт, мене звуть Ава! Я – твій гід зі ШІ. Я допомогу тобі вдосконалити бізнес!
Незалежно від того, чи ви вже керуєте бізнесом, чи мрієте його відкрити, я тут, щоб допомогти перетворити ваше бачення на реальність разом із фрілансерами, які працюють зі штучним інтелектом. Поділіться своїми бізнес-цілями, і разом ми створимо проект, в який наші талановиті фрілансери зможуть подавати заявки. Втілимо ваші плани в життя!
У мене є бізнес
Я відкриваю бізнес
Під час надсилання розмови на вашу електронну пошту сталася помилка. Будь-ласка, спробуйте ще раз пізніше.
Ви можете зберігати вашу розмову лише раз на годину. Будь-ласка, спробуйте ще раз пізніше.
Ваша розмова занадто коротка. Продовжуйте спілкуватися з Авою, щоб увімкнути функцію збереження.

What can we learn from the Iowa Caucus mess?

The Iowa caucus blunder was embarrassing and a faulty app was to blame. In this post we perform a post mortem to uncover some important lessons.
5 лют. 2020 р. • 6 хвилина читання
Фото для обкладинки

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 thatt 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:
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.
e2e testing
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

Аватарка користувача
Прапор Rafal R.
70 USD / hour
5,0 (105 відгуки(-ів))
C Programming
Visit profile
Аватарка користувача
Прапор Orange Techsol
20 USD / hour
5,0 (87 відгуки(-ів))
Ruby on Rails
Game Design
Visit profile
Аватарка користувача
Прапор Xtreem Solution
15 USD / hour
4,8 (163 відгуки(-ів))
PayPal API
Objective C
Visit profile
Аватарка користувача
Прапор W3ondemand
15 USD / hour
5,0 (29 відгуки(-ів))
Shopping Carts
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.
v shaped model sdlc

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.
Розкажіть нам, що вам потрібно зробити
Введіть назву вашого проекту
Розпочніть свій проект
Схожі історії

Поспілкуйтеся з одним із наших технічних помічників, щоб він допоміг вам із вашим проектом

Отримати допомогу зараз

Рекомендовані статті саме для вас

Мініатюра статті The ultimate guide to building a mobile app
Got a great idea for an app? Need a new way to grow your business? We tell you everything you need to know about building a mobile app in 2020.
16 min read
Мініатюра статті What product designers can learn from Disney Plus' mistakes
Disney Plus has arrived with a library full of amazing content, and a product full of bugs. Here's what you can learn from their launch.
6 min read
Мініатюра статті How to make your startup (artificially) intelligent
Artificial Intelligence technology is nothing to be afraid of. We'll show you how to use it to transform your startup
7 min read
Мініатюра статті Your complete guide to hiring a programmer
You can hire a programmer to solve just about any complex problem, the problem is knowing how to hire the right professional for the job. Learn how..
13 min read
Дякуємо! Ми надіслали на вашу електронну пошту посилання для отримання безкоштовного кредиту.
Під час надсилання електронного листа сталася помилка. Будь ласка, спробуйте ще раз.
Зареєстрованих користувачів Загальна кількість опублікованих робіт
Freelancer ® is a registered Trademark of Freelancer Technology Pty Limited (ACN 142 189 759)
Copyright © 2024 Freelancer Technology Pty Limited (ACN 142 189 759)
Завантажуємо для перегляду
Дозвіл на визначення геолокації надано.
Ваш сеанс входу закінчився, і сеанс було закрито. Будь ласка, увійдіть знову.