For novel ideas about building embedded systems (both hardware and firmware), join the 30,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

Jason Long is donating three copies of his brand new book Embedded in Embedded for this month's giveaway. Here's a short review. Enter the contest here.

By Jack Ganssle

Voting Software

Published 5/18/2006

It's an election year here in the United States, and the partisan bickering in Congress is now approaching unparalleled levels of hysteria. Somehow we citizens will have to bear with the accusations and silliness through November.

Then, of course, we exercise our Constitutional right to impose practical term limits (i.e., vote `em out) or to preserve the status quo. In many districts those precious signals of democracy will be recorded and hastened to a (hopefully hardened) database by a variety of electronic voting machines. There's one thing we know will happen: the bickering will only increase as losers contend their constituents' desires were distorted by poor firmware in the machines, or by the lousy procedures used by election workers.

It's not just the machines themselves. Any part of the process controlled by software may be suspect. The ACM recently released a report (http://www.acm.org/usacm/PDF/VRD_report.pdf) about the software used to register voters. Here's a quote:

"In light of recent events and legislation that have underscored the core importance of voting and of public confidence in our electoral system, one might conclude that all VRDs should be built and operated to the highest possible standards. While the highest standards of reliability, privacy, accountability, usability, and security are desirable, they may at times be impractical because of resulting expense or system response."

What - we're expected to <i>intentionally</i> build substandard code?

The assertion that correct code is slow ("system response") is a red herring designed to lull non-techies into accepting buggy code.

Two decades ago the MGM Grand Hotel in Las Vegas burned with great loss of life, in part since there was no sprinkler system. The owners refused to shell out $200,000 for sprinklers, as the city fire codes of the time didn't require them. The fire and resulting lawsuits eventually cost them $200 million. Substandard construction, of hotels and of software, leads to expensive chaos.

The (long) ACM report goes on to focus on using tests to prove the systems are correct. Yet we know testing does not work. Most tests exercise only half the code. While tests are indeed critically important, it's prudent to focus on the internals. How is the code built? Is it inspected. or a spaghetti mess?

Using test alone is like accepting an airplane engine because it runs. The FAA requires all aircraft engines to be totally disassembled every so often to look for latent internal problems.

There's an enormous amount of press now about defects in the voting machines. Reports cite vulnerabilities that leave gaping security holes easily exploited. Others worry about as-yet-unidentified defects that could throw an election. perhaps without anyone ever knowing it. Vendors claim sainthood for their units while keeping the code under wraps.

I know this much is true: voting machine vendors are in the business of selling trust. If we don't trust these machines the electoral process fails. Yet the message the public hears is one of "software is inherently buggy and insecure; deal with it."

I think e-voting is the right idea. It'll make the process faster and more accurate, while opening more opportunities for absentee votes, an important feature in these mobile times.

But a machine built on top of a very complex OS, one that has not been certified correct is a Bad Idea. A machine designed for easy in-the-field patches is a Bad Idea. A machine built of proprietary software is inherently not democratic.

We know how to make fabulously-reliable code. Ironically, some voting machine vendors already do so in their other product lines, like automated tellers. Banks are completely intolerant of any process, teller or software that throws the balance off by even a penny. The gaming industry, too, builds machines of unprecedented reliability. For an interesting look at the difference between the gaming and voting industry, see http://www.washingtonpost.com/wp-dyn/content/graphic/2006/03/16/GR2006031600213.html .

What do you think? Will your vote count?

Do you need to eliminate bugs in your firmware? Shorten schedules? My one-day Better Firmware Faster seminar will teach your team how to operate at a world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and covers the unique issues faced by embedded developers. Here's information about how this class, taught at your facility, will measurably improve your team's effectiveness.