Happy Path Democracy

Unless you’ve completely sworn off politics (honestly, we wouldn’t blame you), you’ll have heard by now about the disastrous failure of the app hired to report results of the Iowa Democratic caucus.

Precinct chairs were supposed to enter primary election results into the app, but many had trouble getting it to work, partly because they weren’t trained beforehand and partly because it was a terrible piece of software. That held up the tabulation of results, which caused anxiety, leading to more user error, more anxiety, and a very long, cold night in Iowa. Worse, customer service reportedly wasn’t answering the hotline set up to deal with issues, so there was nowhere for users to turn.

An untested, unvetted app was deployed for the first time on one of the most important nights of the election cycle. It failed.

In the days since, the chair of the Iowa Democratic Party resigned in shame, Nevada vowed to not use the app after all, and conspiracy theories have been emerging faster than we can read them. That might be a danger when you literally name your app Shadow, but we digress.

Because testing was nearly non-existent before deployment, it was left to people using the app — largely untrained but passionate volunteers — to both navigate the system and prepare for potential trouble. Vice did a tremendous write-up on the technical errors that plagued the Iowa Democratic Party. As a piece of software it was badly conceived, badly coded, and badly implemented.

Ultimately it was a reminder of how critical it is that a software project of this size — or any size — be tested for every possible scenario. And, it’s why we use Behavior Driven Development. BDD’s happy path/sad path structure reveals a wide range of edge cases, meaning that we can predict, with a healthy degree of accuracy, what will happen if a user mis-enters their password, or turns off two-factor authentication, or if it’s freezing in Des Moines.

Because BDD uses plain English, everyone involved in development can write scenarios, which allows for greater input from key stakeholders who might not otherwise be able to participate in some of the most crucial moments. It ties the business needs (“accurately reporting voter counts,” for instance) to the code that’s written. Since the scenarios can be written by business owners and the scenarios create the tests, the code that satisfies the tests satisfies the business requirements. It’s both simple and incredibly powerful.

And it’s why we’d simply never work without it.

We’re not saying BDD would have saved the Iowa caucus. But…we’re not saying it wouldn’t have, either.

Happy path.