The Iowa Caucus Software Failure Was the Classic Software Product Failure

Rather than improving the Iowa caucus vote reporting process, a software project seems to have derailed the kickoff to the 2020 Presidential Election. Under the intense glare of every part of the United States media spotlight, the failures of poor software engineering were laid bare for all to see, throwing the crowd of Democratic contenders into disarray and making irrelevant the historically important first test of a Presidential candidate.

From our perspective as a software consultancy, this failure comes down to one important problem. Those building the software did not effectively consider the aspects of the app which were not directly visible to the user.

Radial runs into this challenge daily with our customers. Often our customers have trouble seeing the value in things that are not a part of an application’s user interface. Often they will nod and write a check for tens of thousands of dollars for a designer to create a beautiful app, but balk at a monthly server budget in the hundreds.

This collides with our process for doing things. At Radial we have strongly defined processes that are designed to maximize long term value and isolate risk for our clients. This process is often difficult for our clients to see. Why, for example, should a client spend extra money for the development of automated tests? Why do we insist that all code we deliver has been reviewed by more than two members of our team?

We have answers to these questions, but often, especially when a client shops around for freelancers or offshore development teams, it costs us a client. And while that does mean we miss out on some neat projects, ultimately it’s a good thing - for everyone.

What happened during the Iowa caucus is to be something that we work to ensure our clients never experience. An app on which an entire state’s highly visible political process depends is an app that cannot fail. When the fallout from this debacle is complete, we believe several things will come to light.

  • The Iowa Democratic party underestimated the requirements and budget of their software needs.
  • The consultant either underbid the work or was unable to explain why the initial estimate was low.
  • The consultant saw huge marketing upside after a successful rollout in Iowa, and drove their staff to complete features rapidly, and without proper oversight.
  • The consultant worried about user-facing features to the exclusion of server infrastructure durability, and accepted developer work that worked on MacBooks using tiny segments of test data, but never tested a real production load.
  • The consultant never used an expert DevOps team to ensure that the app’s infrastructure was appropriate for the load.
  • The consultant never considered failure beyond the features that a user sees.
  • The consultant never considered what to do if the app failed in its entirety.

At Radial, our job is to ensure these types of problem never happen. So we aren’t in it for the short run. We aren’t here to rapidly build you a quick mobile app that should only take a couple weeks to get to the App Store, after which time our relationship is over. We are here to be your partner in the long term technological development of your business. We want our success with your work to be directly tied to your success in your business.

We believe strongly that any code we deliver should be accessible to your most junior developers, maintainable over the long term, founded on competent architecture and dependent technology, and most importantly, built with the customer in mind. We believe that any deployment of software needs to be done securely and using best practices designed to primarily ensure application stability.

An app is more than the things a user can see, and it’s most often those invisible things that cause the biggest problems. It doesn’t matter how beautiful your app is if high traffic crashes your back-end API server, nor does it matter how fast your data can be collated if your database becomes unavailable and drops incoming data.

At Radial, our customers can be sure that we’re providing them with a holistic view of an application. We have considered the work we do from the perspective of a user, but also from the perspective of a business owner who truly understands that what the user sees is the tip of the iceberg.

We have had clients express dismay at our insistence that we do test-driven development, or that we do comprehensive code review, or that we are unwilling to share root credentials to the database on which their application relies so they can perform their own maintenance. While we generally try to find ways to accommodate our clients, they also have to trust us that we have processes in place for tried and true reasons.

We’re experts at this, and we know what it takes to build the things our clients need. We don’t say no capriciously, and we don’t ask for clients to pay us unnecessarily. At the end of the day what we are helping build is their success.