Iowa caucus app woes from a developer perspective

Whether the issues behind the Iowa Democratic Caucus app debacle were specific to UX, connectivity, traffic, or just good ol’ fashioned reluctance to embrace the technology, the ramifications of this mess will be felt for a long time – the hanging chad of the new decade. So are apps out? Absolutely not, but things are going to have to change.

Applications (for both mobile and multi-device) are only growing in importance. Applications have moved beyond widgets, they’re experiences. The issue is embracing them at-scale. We recently caught up with Mendix’s low-code application development expert Jon Scolamiero to get his thoughts on what happened at the Iowa Caucus, how low-code can drive innovations for future elections, and the risks involved for all of us.

ADM: What was the major issue that led to the Iowa Caucus app debacle, from a developer perspective?

Scolamiero: When the news first hit it was pretty clear that the hands-on-keyboard developers are unlikely to be at fault. The Iowa Caucus issues look, sound, and smell like a leadership and management problem from the get-go.

To this point, developers around the globe weren’t surprised to hear that the app had failed so miserably given the elements that lead to its creation. The application was supposedly rushed to completion, and not given ample time for an app that is so critical and in possession of data instrumental to a government election. Not only was it made too quickly, but there was also little to no transparency and input from the most important stakeholders. These problems could have easily been fixed (or avoided altogether) if those in charge of the development had followed three simple steps. 

When developing an app of any size, it is paramount that it is developed with transparency and collaboration between the team and those with a vested interest in the outcome, in this case, the American public, as well as those running the caucuses across Iowa. Those running the creation of the Iowa app tried to deliver something of public importance under a cloud of secrecy. Worse, the real end-users weren’t consulted in its creation.

End users supporting the process would have quickly highlighted the accessibility problems, a core issue with the Iowa app. Red flags would have gone up alerting developers that their app didn’t work on every device being utilized, where these people were and who these people were. Any software created needs to be built in order to provide experiences accessible to all of the intended users (e.g. everyone from a 28-year-old techie through kind-hearted retired volunteers), no matter where they choose to use the app, whether it’s a city building with high-speed internet or the middle of a field with absolutely no connectivity. 

Finally, the app that was used during the caucuses wasn’t built for scale. This lead to many issues, none more apparent than the errors caused when more people were using it than what the app could support. Every developer knows to build for an order of magnitude larger performance requirements than what you expect. 

ADM:  How could low-code have helped prevent the debilitating problems?  

Scolamiero: Had an enterprise-grade low-code platform been used to develop this application, all of the issues highlighted previously could have been avoided or addressed. Low-code tools allow developers from citizen to professional to develop together, while enabling entirely new forms of collaboration with key stakeholders and end-users. The right low-code platform would have enabled the Iowa Caucus volunteers to collaborate at every step of the process without slowing it down. 

It is also important to mention that a holistic low-code platform enables applications to be built natively, allowing them to take advantage of core device capabilities, such as higher performance, and online or offline if necessary. Furthermore, these platforms provide tools to allow apps to automatically scale, avoiding the work needed to allow an app built for 1,000 people service 100,000 or a million.

ADM: Why is low-code useful when creating applications for mass use? 

Scolamiero: Holistic low-code platforms take the pain and friction out of developing (and the struggles that come with maintaining), deploying, and operating a whole software solution. This really speeds up a developer’s ability to deliver without taking away their ability to dive deeply and use code when they need to. Not only does it help with this, but it also enables developers of all skill levels to transparently create and collaborate with each other, the key stakeholders of the solution, and those who matter most, the end-users. The more unique backgrounds, the better, especially when testing applications (something that apparently wasn’t done prior to the Iowa app being released to the masses). Low-code allows developers with different skill levels to measurably deliver.

Besides allowing developers to collaborate, create a more accessible app, and allow the product to be scaled, no matter when it was created, these platforms help with standardizing applications. Therefore, no matter who helped develop the final product, all developers are able to provide updates and scaling can be effortless.   

ADM:  What are the benefits of utilizing solutions that empower citizen developers to create?

Scolamiero: Besides involving more people to help meet product goals (and the aforementioned pro of collaboration), citizen developers bring a number of new skill sets and ideas to the table. Wisely adding citizen developers to the mix can engage a broader population of technical people within an organization who might not consider themselves developers, but who can add deep knowledge in their own fields (e.g. chemistry, engineering, statistics, finance, etc.). This also has the knock-on effect of safely bringing shadow IT out of the shadows and into the mix as productive collaborators in developing solutions for the end-user.

While what happened at Iowa wasn’t overtly caused by shadow IT, or a lack of citizen development, had leadership been able to involve actual citizen developers, red flags might have been raised sooner than the night of the caucuses. One thing developers often struggle with is raising issues, and ultimately having management/stakeholders/leadership ignore them until it is too late. It’s sad to say, but citizen developers can often cause leadership to listen more carefully to feedback due to the fact that they “aren’t technical.” 

ADM: Do you believe that apps will play a part in elections in the future? 

Scolamiero: Eventually, we may live in a world that utilizes voting applications that will allow registered voters to get to the polls from the comfort of their home, but following the recent mess at Iowa, we need to rethink that. Good technologists and developers know that putting key personal data and the process of government in the digital medium can do more harm than good. Some things should be done in the physical world where they are less prone to being hijacked. 

The possibilities are endless, and most of them spell a troubled future for voting and democracy. There’s a chance that something similar will happen but on a grander scale including excluding the most vulnerable from being able to participate in society. You’re also opening up the floodgates for data to be stolen and misused. No digital platform is safe to drive public policy without physical controls.

The list goes on that tallying and voting via a piece of paper might be the better option. The app caused so much trouble for the DNC that some were considering re-caucusing. This debacle, unfortunately, cast a shadow on the integrity of involving new tech in the voting space. 

ADM: How can other city officials be prepared for future primaries/caucuses?

Scolamiero: In order for city officials to be prepared for future events like the Iowa caucus, they must be diligent and wise in how they introduce it. The problem that started the entire domino effect was rushing to get the application done in the first place. Allowing ample time to develop is paramount for success.

Just as important, is ensuring that you’re not involving an outside party or outsourcing your intellectual capital just because you may have heard it’s a good idea to do so. In this case, the app was developed by a lobbyist firm familiar with the party. Keeping ahold of your intellectual capital is important beyond politics - enterprises shouldn’t be outsourcing their key IP either.

Lastly, the most important principle for any software intended for public use/consumption. Be transparent.

ADM: What functionalities does an app like the one used in the Iowa caucus need to have in order to work properly?

Scolamiero: There are a number of precautions and steps the Iowa caucus could have taken to avoid what occurred. Testing the application before it was released to the masses would have been a good first step. Ensuring that there was transparency during the building of the app would have also been beneficial. Involving people outside of the team to see and collaborate to the end goal could have calmed the many headaches that proceeded to happen during the Iowa caucus. 

The main capability, however, would be developing an experience that was accessible to all, no matter their device, age, location, background, etc. During the evening’s proceedings, we saw many struggling to use the app. We also heard from young people who had the newest tech and claimed to have no problem reporting results. Yet, there were also people that had a proper connection to the internet but still struggled to share results. As there wasn’t an offline system implemented, people in areas with inconsistent service had issues even connecting to the online portal.

There is something to be said for creating features that allow recording physical results digitally as well. 

ADM: What are the security risks for election applications? How does low-code help safeguard against inherent security risks for applications, especially around elections?

Scolamiero: The biggest security risk for election applications (and applications in general,) is not ensuring proper transparency during the development process. When you have a siloed or small group of people working on a solution in secret, and not properly testing it, not only are you opening up the risk that the app won’t be suitable for the users, but that it also has exploitable security vulnerabilities? 

One of the best perks of developing with an enterprise-grade low-code platform is that it is consistently tested and evaluated by recognized third parties to ensure that it is secure enough for even the most demanding customers. It is in the best interests of a real enterprise-grade low-code platform to be able to transparently prove the stability and security of the platform.

In addition, holistic low-code platforms provide clear guardrails around things such as appropriate security best-practices and well-known exploits. This helps ensure that those building the app are kept well informed as to the decisions they are making and how they impact security risk.

ADM: From a developer’s perspective, does the model of phone being used to download the app have any effect on its performance? Could the code behind the failed app not have been created with functionality across various devices?

Scolamiero: From a developer's perspective, yes the model of phone can have an effect on the application's performance due to different hardware specs. It’s imperative for designers to build an app that is native so no matter the device or the person using it (and wherever they are), it should function as it was designed to. Not to mention the providers of the software need to be clear what devices and performance profiles are supported. 

Holistic low-code platforms can be incredibly valuable when developing mobile and multi-experience apps. The right platform enables developers to create mobile apps like they would any other app, and yet provide a truly native experience on the device being used. Whether it’s iOS, Android, or a browser, solutions can be delivered from a single project, yet tailored for each device. Not to mention exposing what devices and hardware profiles should be used to ensure the proper experience.

ADM: Anything else you’d like to add?

Scolamiero: What happened in Iowa isn’t an isolated case. There have been problems (and will continue to be problems) around developing applications that adhere to necessary, but completely feasible, guidelines. In fact, these issues are truly endemic to how most leadership teams drive software delivery. Development teams of all types will continue to run into similar issues until their leadership makes transparency, accessibility, and scalability priorities by planning to invest the appropriate time and money.

A part of the solution is to make it easier to get stakeholders & end-users involved in making, using, and helping to scale software solutions. Honestly, holistic low-code platforms like Mendix truly provide tools to do this for problem solvers from every range of skill levels. This helps mitigate issues by bringing those building and using solutions together. While it’ll always be up to people to solve problems, the right low-code platform helps facilitate the entire process. While we wait for someone to create an application that can withstand issues we saw in Iowa, we should focus on tallying and voting in a simple, secure, but efficient way - paper.