Reliable vs. Trustable, Take 2

So a couple of people have now pointed out that my efforts to divide reliability and trustworthyness ended in confusion.

To simplify:

When we interact with things, we form an idea in our minds of how the things are going to behave.

➡ If the thing always behaves how we expect it to, that is trustworthy.

➡ If the thing always behaves the same, even if it is unexpectly the same, that is reliable.

In the recent election, voting machines proved their reliability. For the most part they were very consistent in their behavior. On the other hand, the final results diverged a bit from the polls, which some people did not really expect. As a result, they are lacking in trust.

But then, what reason would someone have to prefer to mistrust the voting machine rather than the polls?

Reliable vs. Trustable

Why is it that people have such a hard time with such simple concepts? Reporters seem to get a free pass to be almost unbearably confused about subtle differences. What am I blathering about? I'm glad you asked!

Reliability is the idea that something will perform consistantly.

Trustable is the idea that something will perform how you expect it to.

So what is the difference? Well for simple things, things that people can understand just by looking at them, this tends to not be an important distinction. For complex things, things like computers or things built around computers, this difference gives people some trouble. Let's start by thinking about simple things.

I have on my desk a piece of paper, a pencil and an eraser. These things are all hopelessly outdated by the PDA which I carry about with me, but I trust them. Why do I trust them? Because over the years I have determined that these objects do what I expect them to. I also think of them as being reliable. Why is that? Well, for the most part they operate every time.

There are, without a doubt, some failures. Paper is not the most robust storage medium one can imagine for putting in a pants pocket and running through the laundry. Rough handling of the pencil will result in a broken lead. If the paper gets oily or I write too hard, sometimes it just does not erase too well. Depending on my mental model of what paper, pencil and eraser should do, these might be classified as trust issues, or as reliability issues. I have a fairly sophisticated model in my head of what paper, pencil and eraser do, so for the most part I think of these as reliability issues. I trust that if I run a paper through the laundry, it will come out useless. I trust that if I roll over my pencil with my desk chair it will afterward have issues. Since my mental model does a good job of predicting how the system will behave, and it is generally right, these are reliability issues.

I have in my living room a VCR. The clock on my VCR does not blink 12:00. In fact, every time I put a videotape in the mouth, I can watch it. Unless the tape is too old, in which case it might eat it. I have a mental model built up about that, so it is a reliability issue. Fine. But if I should want to record a show using the built-in timer functionality: Tough luck. The few times I did try to set that up, I ended up losing any semblance of confidence and just starting it manually on the slowest recording mode and hoping that the tape was long enough. That is a failure of trust. The trust issue is the most frustrating.

Software bugs, due to their complexity, tend to be trust failures. Software bugs that are simple enough to produce a useable mental model to compensate for are generally also the ones that get fixed. Because they're simple.

Prior to our recent election, we've seen computer scientist "e-voting experts" pontificate mightily about how computerized voting is not reliable. Well, the election went pretty smoothly. There have been some noteworthy failures, mostly in the screen calibration, but no widespread looting or anything like that. Why? The machines are reliable. That's why they were concieved as a replacement for paper balloting. The reliability of a direct interface is better than the reliability of marking cards or paper or something and then letting a computer count that.

So, now they'll quit whining, right? Wrong. Now they'll have to be a bit more clear about what they are objecting to. The machine's reliability is really pretty good. They're designed to keep backup copies of all the really critical data. The problem is that after being exposed to too much buggy software, these scientists just don't trust them to do what they're supposed to.

So, when bugs get revealed it only seems natural to distrust the machines, right?

Does nothing ever change?

Four years ago, America was introduced to the idea that using punchcards to vote might not be the very best way. It turns out that the information about the vote is not stored in the card itself, but rather in the very delicate little pre-scored edges around the "chad". The problem is that with handling the "chad" can come loose, damaging the information stored on the card. Another problem is that hypothetically a very weak person might not be able to produce the couple of grams of pressure required to actually tear out these pre-scored little bits of cardstock, giving rise to the idea of a "dimpled" or "pregnant" chad.

A lot of uproar came about because the voters were not able to adequately verify that their vote was cast as they intended.

In a piece of paper.

Now, there are groups of politically charged activists out and about complaining about computerized voting systems. The issue is that the voters are not able to adequately verify that their vote was cast as intended. On this score they are right. Sadly, they think that there is an easy solution. They want to have the machine print out the voter's choices.

On a piece of paper.

Gives them something to recount, they say. A manual recount is the only way to be sure that the election was done right, they say. What? I have to wonder, do they really think that people are better able to add up numbers than a computer is? Was Herman Hollerith really wrong 123 years ago? And it took us this long to figure it out?

Something seems wrong here to me.

Programming with Comments

I seem to be addicted to mailing lists.

I used to (back when I was in college, so it is getting to be a while now) read USENET a lot. It quickly became apparent that each newsgroup only had two or three topics, and that they cycled through them on approximately a two-month period. But that is alright. There are so many different groups that there is always something new to read.

I rarely ever post, though.

I can't do anything more than speculate as to why this is true, but nearly any thread that I posted to died instantly. [For the non-USENET savvy, a thread is a series of posts, usually between 2-5 people where they "reply" to each other's posts by ignoring whatever was said and restating their own opinions.] I've tried tones ranging from friendly, through concecending, to downright hostile. Always the same. Dead. Even when I ask questions in groups that seem to be good about answering questions. Usually it is as if I never even posted. Dead.

So I rarely ever post.

Because that makes my reading material stop.

So one of the mailing lists I subscribe to is dedidcated to discussions around the Squeak Smalltalk language. And recently they had a discussion about class comments. The jist of the conversation centered around what was a reasonable minimum amount of documentation to require in a program. Some people were of the "if the code requires comments, it is poorly written and should be refactored until it is readable." While I think it is good to put some effort into making the program by itself readable, I have written a pretty substantial amount of code that no amount of refactoring would ever make understandable without some basic comments. A couple people wanted a comment on everything, but that's just as clearly overkill. A sort of reasonable comprimise seems to be to only really require writing one comment for each class of object in the program. That's probably more reasonable, but to me still seems wrong.

Knuth wrote the Web book some years ago, but somehow it's never really caught on. Funny. When I read it back while I was in college, it seemed like such a good idea. The downside was that it was so painfully mechanical. Everything about it just seemed to hurt when I tried to do it.

Squeak Smalltalk has this interesting property where not only is the code and the data all mixed up and interchangable, the program being built is mixed up with the environment it's built in and even mixed up with the tools being used to build it. The resulting slurry can be confusing to the outsider, but once you develop the taste for it, it goes down smooth.

So now I wonder, maybe if there is a way to build a hypertext document in Squeak objects which describes an object class. It could have pictures, sounds, animations, whatever helped to tell the story. But part of the story would be the actual code that would control the behavior. Just like Knuth's Web, the idea is to make the description be the program, and put just enough extra tidbits into it so that the computer could actually execute it.

Too bad I'm to lazy to ever try building it.

How does one become an Expert?

Yesterday, someone at work pointed out this travesty to me. On the one hand, I applaud their desire to scratch their itch. Even in public. Scratching in public is apparently important for baseball players and voting activists. The content of their posts has a little too much of the breathless, cross-eyed, oh-my-isn't-this-exciting flavor to it for my taste, but then I think that salsa tastes good on french fries.

No, the thing about it that bugs me is that it is a group of ten dudes, most of which are computer scientists (like myself), no two of which have the same depth nor breadth of experience in working with voting machinery or election systems as I have.

Maybe no three.

Let's do a quick poll. How many here have served as lead architect and senior programmer on the construction of DRE software which was NASED certified? How many here have served as lead architect and senior programmer on a system to allow overseas servicemen to vote with the same level of confidence (or probably higher) that their votes were successfully delivered and counted as people who vote at a poll site? How many here can speak intelligently about CESG's voting methodology? How many here reasonably understand the statistical analysis of election confidence given a Voter Verified Paper Audit Trail? How many here can reasonably explain to a lay person how Chaum's or Neff's voter verifiable crypto systems work to protect both the privacy and the integrity of a vote?

Me. Maybe someone else, but I rather doubt that there are too many.

Avi Rubin was interviewed for November's Dr. Dobb's Journal. Right on the cover, he is called " the world's leading authority on electronic voting and software engineering." Wow. He must've done some pretty impressive work to qualify for such a description. What does google say about "avi rubin software engineering"? A little bit of stuff, like building a firewall to stop java applets. Kind of security related, even. A lot of stuff about how Rubin is an e-voting expert. But that's not really relevant, since it's just sort of tautaulogical. How about "avi rubin voting machine"? H'm, this is more promising. The very first hit is to his very own web site, where he discusses in some depth his apparently first experience as an election judge. There are no dates given on this page, but it appears to post-date the Analysis of an Electronic Voting System which appears to have been published in May of 2003 (the date at the top of the page notwithstanding). As far as I can tell, this is the earliest example of Avi doing anything with respect to voting systems.

So far, I don't understand how he came to be the worldwide leader.

I, in comparison, have been working full time since the January 2000 not on criticizing the efforts of others, but on finding and building workable solutions to the problem of how to run an election in the twenty-first century.

What, no posts?

Sorry about the no posts for the last couple days. I don't actually know if it was this "blogger.com" site or my computer or what, but I was unable to get a post through. I plan to make up for this neglect Real Soon Now (tm).