I worked the election in my county yesterday, and something that came to my mind was the computerized voting machines.  These voting machines run software, and this software is in charge of keeping track of votes.  This job is very important, and if the code has bugs, it could lose track of votes.  My precinct uses bubble-in ballots, so there is NO doubt what the vote is.  We see on the paper the selections.  Some of these voting machines take in data and then report on it.  We just have to TRUST that the report is accurate.  Because of that, we have to TRUST that the software has no major bugs, and that is TRUSTING the developer who wrote the software.  These machines perform such an important job, that I believe we shouldn’t just TRUST the software. 

This situation resonates with me in normal software development.  Sometimes when a user has a problem, my response includes something like “just do this, and the software with do this and that and then show you the result.”.  I just EXPECT that the user will trust the software, but some users aren’t comfortable with that, and I know that if I don’t know how some software works internally, I’m skeptical about it.  Going forward, I’m going to make an effort to provide more detail about what the software is doing to the user. 

Logging is another issue.  If I have code that does a series of things and then spits out a result, but it doesn’t log intermediate data, how do I find where I went wrong if the result is wrong?  Same with voting machines.  If they spit out a completed paper ballot after every voter, this paper trail would ensure than no malfunction ever lost votes.