Last year, the world was treated to an amazing demonstration of unintended design consequences, packaged as the 2000 U.S. presidential election.
I know, I know, you’ve heard enough about the election and the insufferable Florida recount. But bear with me here, for the system design aspect of the voting fiasco in Florida is a classic lesson of how bad design can have much more significant implications than ever envisioned. I refer here to the lowly voting machine and the simple task of marking and counting a ballot.
I’m probably spoiled in this area because in Canada we just make a mark on a sheet of paper next to our desired candidate’s name. Any mark is considered valid, no "hanging or pregnant chad" issues there. Importantly, this process has visual verification and feedback (important with all tasks), and it allows me, the voter, to check my choices before submitting the ballot.
Many people were amazed to discover that thanks to automated voting machines in Florida last November, invalid or unreadable ballots could reach 10,000 to 25,000 in number in a single county. The plot thickened when broadcast courtroom testimony noted that the machines did not really give the user notification that he or she had voted successfully, nor did they allow the voter to check the results. In other words, no feedback.
Further testimony noted that the machines had not been emptied from the previous elections, and may have been jammed with old chaff from previously punched ballots. So there were few, or no, required procedures for checking the machines’ election serviceability prior to their use.
The visually confusing "butterfly" ballot was found to be misleading. A human interface problem? Who out there is prepared to give up their vote as an "acceptable failure rate" for the convenience of voting machine manufacturers?
Looking at the voting situation from a design perspective, these were some key issues:
The machines used a ballot that acted as a template for the voter to punch a card underneath based on his or her candidate selection. This awkward process only aided in counting the ballots, not in casting a vote. And they even failed miserably in the counting process, as tens of thousands of cards could not be read.
The machines did not indicate to the voter if a vote had actually been made (hardly an insurmountable engineering challenge). It also did not indicate when it was full of punched chaff from previous use, so no one really knew if the machines were ready for use.
The cards used have to be pre-die cut to allow the voting process to work. This can deliver massive variation in the process with regard to "feel" and clean punching.
Finally, when the card is removed, there was no way for the voter to confirm his or her selections.
The voting machines in Florida may or may not represent great engineering, although I’m certain the "demo" went well enough at the original sales presentation. Kind of like the bug-ridden software I wrestle with regularly.
But look at what this flawed engineering delivered: a rather humiliating month-long display of partisanship, misdirection and instability, all created by a bad design. Broadly speaking, the aviation industry can learn much from the 2000 U.S. election–that marginal design always finds a way to express itself at some point in unintended ways.
Our industry has many similar situations brewing, such as the relentless drive for GPS-only navigation, a violation of the "two independent nav sources" rule for instrument flight. Nonetheless, to some, there are good reasons to mush ahead, even though numerous scenarios exist that could cause a global or regional shutdown of satellite navigation. Perhaps the voting machine guys are getting into the navigation field.
I know that far smarter minds than mine have spent a lot of hours on GPS use and other issues, but I’m troubled to see large-scale design make its way into the unsuspecting world with significant unresolved issues seemingly dangling like a hanging chad.
My point is simple, spend the extra time, ask all the questions, invite others to observe and comment, try and break it, do all the tests, and be sure you’ve done the very best on every design. And then revisit the device you have designed once it’s up and running to see how it works in the field. The consequences can be as great as the Florida recount.
Walter Shawlee 2 may be reached by e-mail at firstname.lastname@example.org.