What the Iowa Caucuses Can Teach Us about App Development
Privacy Plus+
Privacy, Technology and Perspective
What the Iowa Caucuses can teach us about app development: This week, we consider how a quest for quicker Iowa caucus backfired with an app that, in part, caused delays in reporting. For more about the details Iowa debacle, you can read these articles by clicking on the following links:
As post-mortem, we provide the following question and answer:
Question 1: Why was Iowa’s caucus reporting such a mess?
Answer: Because it was required to be done over a cell-phone app that was
(a) nearly impossible to load;
(b) buggy;
(c) delivered over a test platform;
(d) not backed up by a reliable system; and
(e) insecure.
Turning to the practical lesson:
Question 2: What lessons can private business learn from this?
Answer: There are at least six:
1. Conduct due diligence.
With respect to app development, consider how procurement decisions will be made. Is there a Request For Proposal (RFP) process and a diligence review of:
· Security of systems (SSAE 16 or similar audit);
· Financial review;
· Legal review;
· Corporate structure and stability; and
· The developer’s annual spend?
Are any parts of the development services outsourced to sub-contractors? If so, who are those sub-contractors and what steps were taken to vet those subs? When the integrity of your app is stake, don’t you really want to know who is responsible for building the app? We think the answer is yes, especially when an election is at stake!
2. Contract appropriately.
Require (in writing) that your app be easy for its intended audience to use.
The Iowa app was intended to be used by caucus chair-persons -- many of whom have been described as “need[ing] their grandkids to program their VCRs.” Yet it required many complex steps to load.
The take-away: Never mind whether you can use it. Particularly ignore how excited your developers are about it. Can your intended users use it? – comfortably, and well?
Develop a bright-line specification that translates into “our intended users can use it comfortably, and well,” and add it into the Statement of Work and acceptance criteria.
3. Test, test, test. Test some more. Wait a bit, then test again.
The Iowa app was not adequately tested. The result was too many bugs and a high failure rate.
Particularly test at close to the scale required. Test platforms may work differently when deploying at scale. See no. 4 below.
The corollary to this is allow enough time. Apparently, a few tests were run on the Iowa app, and showed significant problems which there wasn’t enough time to fix.
4. Deliver your app over real delivery platforms – Apple’s App Store, Google Play Store – not test platforms.
The Iowa app was delivered over test platforms (Apple Test Flight, iOS and Android Test Fairy). These are fine for development work, particularly beta tests; but they may become unstable when deploying at scale. That happened here.
Before releasing apps to consumers, App Store and Play Store will require close review to confirm they are free of malware and meet other requirements. Test platforms are intended for apps that haven’t reached that stage of development.
The Iowa case was especially bad because the developer used Test Fairy’s free version, which wouldn’t allow more than 200 users anyway.
(Practical Hint: if it has “TEST” in the name, maybe it’s not the best platform to deliver your end-user software at scale.)
5. In critical situations, have a contingency plan.
“Contingency plan” is not the same thing as “back-up,” as in “backing up data.” Of course you want to have continuous data back-up, but in situations like Iowa, you also need to have available an alternative, redundant system in case the app which your developers have assured you will always work, doesn’t.
Iowa should have maintained its traditional, call-in telephone system that it has used for many years. Iowa still had a call-in system, but it was overwhelmed by calls from puzzled/frantic caucus chairs calling in all at once from all over the state.
No doubt, everyone had expected the app to work. But the Titanic was supposed to be unsinkable.
(To be clear, the unusual Iowa system requires caucus-goers to stand up and show their preferences openly in front of everyone, which are also confirmed on paper. So the issue has never been whether the app jiggled the vote totals around, as the first reports of trouble suggested. The totals will “get there” eventually. But Iowa could not deliver result information at the speed of light as everyone had been led to expect, and this resulted in hysteria.)
6. Know thy developer (and its subcontractors), prioritize security, and require clear, written reps and warranties.
The Iowa app-developer was “Shadow, Inc.” – perhaps an odd choice of name in an industry where the best-practices require transparency and knowing your vendor. See no. 1 above. In any event, the “test” platforms had not yet been vetted for security and at least in the “free” version one of them used, did not require end-to-end encryption.
In any app development, you must require specific, written reps and warranties not only of performance, but also of data protection including both data security and limited use and transmittal.
---
Hosch & Morris, PLLC is a Dallas-based boutique law firm dedicated to data protection, privacy, the Internet and technology. Open the Future℠.