Viewing entries tagged
complexity

Comment

NJ Election Officials, Displaced Voters, Email Ballots, and more

There's plenty of activity in the NY/NJ area reacting to voters' difficulties because of Super-Storm Sandy, including being displaced from their homes or otherwise unable to get to polling places. As always, the role of technology captured my attention. But first, the more important points. Some displaced people are having trouble even finding a place to shelter temporarily, so extra special kudos to those that manage to vote, whatever the method of voting they use. Likewise, extra praise for NJ and NY election officials putting in the extra extra-hours to be available to voters in advance of the election, inform them about changed polling places, and equip them to get the word out to their neighbors. The amount of effort on both sides is a great indicator of how seriously people take this most important form of civic activity.

Next, the technology, and then the policy. On the technology front, Gov. Christie of NJ announced an emergency (and I hope temporary) form of voting for displaced voters: sending an absentee ballot via email. That's a bad idea in the best of circumstances -- for several reasons including the vulnerability of the email data in transit and at rest, and the control of the e-ballot by people who are not election officials -- and these are not the best of circumstances. For example, I doubt that in every county elections office in NJ, somebody has a complete list of the people with access to the email server and the ability to view and modify data on it.  But while you can see that Christie's heart in the right place, there are several issues beyond these, as described in a NJ news report here.

And this is only one of the emergency measures. In both NJ and NY people can cast a provisional ballot at any polling location -- see NJ's announcement here, and if you have the similar one for NY, please provide it as a comment!

Finally, on the policy side, it's not even clear what these ballots represent, and that's the policy problem. My legal and policy colleagues here at TTV, and in the legal side of the election integrity community, certainly know more, but I don't! Are the provisional ballots cast under these emergency rules required to be processed exactly the same as non-emergency provisional ballots? Are the e-mailed ballots provisional ballots or absentee ballots? If so, what serves as the affadavit? Do the email ballots have to be followed up with the paper hardcopy that the voter scanned and faxed? (The NJ Lt. Gov. office has issued some seemingly inconsistent statements on that.) If not, what happens in a recount? If so, why email the ballot at all, rather than just emailing a "my ballot is coming soon" message?

I could go on and on, but I think you get the idea. The general issue is that in the case of a close election (most likely a local election, but state house or congress, you never know!) there will be some of these not-exactly-your-regular ballots involved, and the potential for real disputes -- starting with concerns over dis-enfranchisement of people mis-informed about how to do a "displaced vote", and going all the way to dispute about whether counted ballots should have been counted, and whether uncounted ballots should be counted. But let's hope that it does not in fact get that messy in NY and NJ, and that every voter is able to make the extra efforts for their ballot to be cast and counted.

-- EJS

Comment

Comment

Online Voter Registration for Jurisdictions Large and Small (Part 2)

My last posting was a bit of a cliff-hanger (sorry) for the claims that:

  • We're doing useful work to enable NGOs and election officials to offer online voter registration assistance to voters ...
  • ... without doing a major acquisition or system integration of the scale that VA is doing now (with OSDV help) or that WA has done or CA is doing in a similar way ...
  • ... but rather using a middle way, between those large projects and the "download this PDF to fill out by hand" kind of support.

The key here is to enable election officials to extend a major change in usability, while spending modest time and effort to quickly stand up an online voter registration assistance service.

As I wrote earlier, we took the first step a few weeks ago when we went live with a new release of the "Rocky" OVR assistance system operated by RockTheVote and hosted by Open Source Labs. The main feature of the new release was a web services application programming interface (API) that provides other web applications with access to all of Rocky's functions for voter registration assistance. Now it is time for me to connect the dots from there to actual benefit for voters and election officials -- starting with an explanation of what the API is.

If you take a test drive of "Rocky" you will see a human interface for people and their browsers to interact with Rocky. By contrast, the programming interface is for other web sites to interact with Rocky, or indeed any software including mobile apps and FaceBook apps. Another web site could implement its own separate human interface -- different branding, different workflow -- while a mobile app could assist the user by pulling information stored on the mobile device. But either way, the web site or mobile app does not need to have any back-end. Instead, they rely on Rocky for checking user data, constructing PDFs, storing registrant data, sending email reminders, and so forth.

As a result, we've substantially lowered the cost in time and effort for any elections officials or NGOs to develop and deploy their own online-voter-assistance system, by opening up Rocky to be the back-end for these systems, so that all the complexity -- and cost of deployment! -- of the back-end functionality just drops out of these systems. No database to set up and manage, no computational heavy lifting. For organizations that already have a web site, it can be as simple as adding one or a few new forms pages, with a link to Rocky that will submit the voter's registration information, and present back to the user the PDF with their completed form and mailing instructions.

Any organization can use Rocky via the API in this way, including local elections offices that already have a Web site that they can update to use the Rocky API. And for local election officials in particular, there is an additional benefit. Via the API they can obtain a digital copy of the voter registration form data, and a tracking number. When the signed paper form arrives in the mail, they can type or scan in the bar-coded tracking number, and get the form data, so that they don't have to retype all the information on the form -- a time consuming (and in peak voter registration season, expensive)  task with much scope for human error.

There's a lot to like about this approach, but it gets even better. In an upcoming release there will be even more features that will help organizations have the very own Rocky OVR system, but without having to have an existing web site that is easy to modify. Depending on how fancy an elections org wants to customize the look and feel, it could be a matter of a couple hours work to get up and running. Even better! More on that when the system is live.

-- EJS

Comment

Comment

At the Risk of Running off the Rails

So, we have a phrase we like to use around here borrowed from the legal academic world.  Used to describe an action or conduct in analyzing a nuance in tort negligence, is the phrase "frolic and detour."  I am taking a bit of detour and frolicking in an increasingly noisy element of explaining the complexity of our work here.  (The detour comes from the fact that as "Development Officer" my charge is ensuring the Foundation and projects are financed, backed, supported, and succeed in adoption.  The frolic is in the form of commentary below about software development methodologies although I am not currently engaged or responsible for technical development outside of my contributions in UX/UI design.)  Yet, I won't attempt to deny that this post is also a bit of promotion for our stakeholders -- elections IT officials who expect us to address their needs for formal requirements, specifications, benchmarks, and certification, while embracing the agility and speed of modern development methodologies. This post was catalyzed by chit-chat at dinner last evening with an energetic technical talent who is jacked-up about the notion of elections technology being an open source infrastructure.  Frankly, in 5 years we haven't met anyone who wasn't jacked-up about our cause, and their energy is typically around "damn, we can do this quick; let's git 'er done!"  But it is about at this point where the discussion always seems to get a bit sideways.  Let me explain.

I guess I am exposing a bit of old school here, but having had the formal training in computer systems science and engineering (years ago) I believe data modeling -- especially for database-backed enterprise apps -- is an absolute imperative priority.  And the stuff of elections systems is serious technology, containing a significant degree of fault tolerance, integrity and verification assurance, and perhaps most important a sound data model.  And modeling takes time and requires documentation, both of which are nearly antithetical in today's pop culture of agile development.

Bear in mind, the TTV Project embraces agile methods for UX/UI development efforts. And there are a number of components in the TTV elections technology framework that do not require extensive up-front data modeling and can be developed purely in an iterative environment.

However, we claim that data modeling is critical for certain enterprise-grade elections applications because (as many seasoned architects have observed): [a] the data itself has meaning and value outside of the app that manipulates it, and [b] scalability requires a good DB design because you cannot just add in scalability later.  The data model or DB design defines the structure of the database and the relationships between the data sets; it is, in essence the foundation on which the application(s) are built.   A solid DB design is essential to achieve a scalable application.  Which leads to my lingering question:  How do agile development shops design a database?

I've heard the "Well, we start with a story..." approach.  And when I ask those who I really respect as enterprise software architects with real DB design chops, who also respect and embrace agile methodologies, they tend to express reservations about the agile mindset being boorishly applied to truly scalable, enterprise grade relational DB design that results in a well performing application, and related data integrity.

Friends, I have no intention of hating on agile principles of lightweight development methods -- they have an important role in today's application software development space and an important role here at the Foundation, but at the same time, I want to try to explain why we cannot simply just "bang out" new elections apps for ballot marking, tabulation, or ballot design and generation in a series of sprints and scrums.

First, in all candor, I fear this confusion rests in the reality that fewer and fewer developers today have had a complete computer science education, and cannot really claim to be disciplined software engineers or architects.  Many (not all) have just "hacked" with, and self-taught themselves, development tools because they built a web site or implemented a digital shopping bag for a friend (much like the well intentioned developer my wife and I met last evening).

Add in the fact, the formality and discipline of compiled code has given way to the rapid prototyping benefits of interpreted code.  And in the processes of this new modern training in software development (almost exclusively for the sandbox of the web browser as the UX/UI vehicle) what has been forgotten is that data modeling exists not because it creates overhead and delays, but because it removes such impediments.

Look at this another way.  I like to use building analogies -- perhaps because I began my collegiate studies long ago in architectural engineering before realizing that computer graphics would replace drafting.  There is a reason we spend weeks, sometimes months traveling by large holes in the ground with towers of re-bar, forms, and concrete pouring without any clue of what really will stand there once finished.  And yet, later as the skyscraper takes form, the speed with which it comes together seems to accelerate almost weekly.  Without that foundation carefully laid, the building cannot stand for any extended period of time, let alone bear the dynamic and static weights of its appointments, systems, and occupants.  So too, is this the case with complex, highly scalable, fault tolerant enterprise software -- without the foundation of a sold data model, the application(s) will never be sustainable.

I admit that I have been out of production grade software development (i.e., in the trenches coding, compiling; link, load, dealing with lint and running in debug mode) for years, but I can still climb on the bike and turn the pedals.  The fact is, data flow and data model could not be more different.  The former cannot exist without the latter.  It was well understood and data modeling has demonstrated many times that one cannot create a data flow out of nothing.  There has to be a base model as a foundation of one or more data flows, each mapping to its application.  Yet in our discussion punctuated by a really nice wine and great food, this developer seemed to want to dismiss modeling as something that can be done later... perhaps like refactoring (!?)

I am beginning to believe this fixation of modern developers with "rapid" non-data-model development is misguided, if not dangerous for its latent time shifted costs.

Recently, a colleague at another Company was involved with the development of a system where no time whatsoever was spent on data model design.  Indeed, the screens started appearing in record time.  The UX/UI was far from complete, but usable.  And the team was cheered as having achieved great "savings" in the development process.  However, when it came time to expand and extend the app with additional requirements, the developers waffled and explained they would have to recode the app in order to meet the new process requirements.  The data was unchanged, but processes were evolving.  The balance of the project ground to a halt in the dismissal of the first team over arguments about why requirements planning up front should have been done, and they figured out who to hire in to solve  it.

I read somewhere of another development project where the work was getting done in 2 week cycles. They were about 4 cycles away from finishing when on the tracker schedule a task called "concurrency" appeared for the next to last (penultimate) cycle.  The project subsequently imploded because all of the code had to be refactored (a core entity actually was determined to be two entities.)  Turns out that no upfront modeling led to this sequence of events, but unbelievably, the (agile) Development Firm working on the project, spun this as a "positive outcome;" that is they explained, "Hey, its a good thing we caught this a month before go-live."  Really?  Why wasn't that caught before that pungent smell of freshly cut code started wafting through the lab?

Spin doctoring notwithstanding, the scary thing to me is that performance and concurrency problems caused by a failure to understand the data are being caught far too late in the Agile development process, which makes it difficult if not impossible to make real improvements.  In fact, I fear that many agile developers have the misguided principle that all data models should be:

create table DATA
 (key INTEGER,
 stuff BLOB);

Actually, we shouldn't joke about this.  That idea comes from a scary reality: a DBA (database architect) friend tells about a development team he is interacting with on an outsourced State I.T. project that has decided to migrate a legacy non-Oracle application to Oracle using precisely this approach.  Data that had been stored as records in old ISAM type files, will be stored in Oracle as byte sequences in Blobs, with an added surrogate generated unique primary key.  When he asked what's the point of that approach, no one at the development shop could give him a reasonable answer other than "in the time frame we have, it works."   It begs the question: What do you call an Oracle Database where all the data in it is invisible to Oracle itself and cannot be accessed and manipulated directly using SQL?  Or said differently, would you call a set of numbered binary records a "database," or just "a collection of numbered binary records?"

In another example of the challenges of agile development in a database-driven app world, a DBA colleague describes being brought in on an emergency contract basis to an Agile project under development on top of Oracle, to deal with "performance problems" in the database.   Turns out the developers were using Hibernate and apparently relied on it to create their tables on an as-needed basis, simply adding a table or a column in response to incoming user requirements and not worrying about the data model until it crawled out of the code and attacked them.

This sort of approach to app development is what I am beginning to see as "hit and run."  Sure, it has worked so far in the web app world of start-ups: get it up and running as fast as possible, then exit quickly and quietly before they can identify you as triggering the meltdown when scale and performance start to matter.

After chatting with this developer last evening (and listening to many others over recent months lament that we're simply moving too slowly) I am starting to think of Agile development as a methodology of "do anything rather than nothing, regardless of whether its right."  And this may be to support the perception of rapid progress: "Look, we developed X components/screens/modules in the past week."  Whether any of this code will stand up to production performance environments is to be determined later.

Another Agile principle is of incremental development and delivery.   It's easy for a developer to strip out a piece of poorly performing code and replace it with a chunk that offers better or different capabilities.  Unfortunately, you just cannot do this in a Database.  For example: you cannot throw away old data in old tables and simply create new empty tables.

The TrustTheVote Project continues to need the kind of talent this person exhibited last evening at dinner.  But her zeal aside (and obvious passion for the cause of open source in elections), and at the risk of running off the (Ruby) rails here, we simply cannot afford to have these problems happen with the TrustTheVote Project.

Agile methodologies will continue to have their place in our work, but we need to be guided by some emerging realities, and appreciate that for as fast as someone wants to crank out a poll book app or a ballot marking device, we cannot afford to short-cut simply for the sake of speed.  Some may accuse me of being a waterfall Luddite in an agile world; however, I believe there has to be some way to mesh these things, even if it means requirements scrums, data modeling sprints, or animated data models.

Cheers GAM|out

Comment

Comment

NY Times: Hanging Chad in New York?

NYT reported on the continuing counting in some New York elections, with the control of the NY state house (and hence redistricting) hanging in the balance. The article is mostly apt, but the reference to "hanging chad" is not quite right. FL 2000's hanging chad drama was mainly about the ridiculous extreme that FL went to in trying to regularize the hand re-counting rules for paper ballots, while each time a ballot was touched, the rule could change because the chad moved. In this NY election, the problem is not a re-count, but a slow count; not problems with the paper ballots per se, but with the opscan counting system; and not a fundamental problem with the ballot counting method, but several problems arising from poll-worker and election officials' unfamiliarity with the system, being used for the first time in this election. Best quote:

Reginald A. LaFayette, the Democratic chairman of the Board of Elections in Westchester, said older poll workers had trouble reading the vote tallies printed out by the machines. “You take the average age of an inspector, it’s maybe about 65, and so you put a new product out with them, and the change has been overwhelming to some of them,” he said.

It's another example of the of situation I recently described in North Carolina. These voting systems were built for time-to-market, rather than designed, engineered, and tested for usability and reliability -- much less designed for simplicity of the process of combining tallies into election results.

The recent experience in New York is nothing truly new - but rather an example of the usability issues manifested in an election organization that, unlike those elsewhere using similar voting system products, has not yet learned by experience how to use these quirky systems with greater speed and transparency than the first time around. Of course, it is a shame that this type learning-by-doing in real elections is necessary at all, to get to a reasonably transparent election process. But that's what the vendors served up the market, and that's what TTV is working to improve on.

-- EJS

Comment

Comment

Bruce Schneier on "Worst Case Thinking"

Although he was talking in a very different context, I still think that Bruce Schneier's perspectives on worst-case thinking have relevance to us:

"Worst-case thinking means generally bad decision making for several reasons. First, it's only half of the cost-benefit equation. Every decision has costs and benefits, risks and rewards. By speculating about what can possibly go wrong, and then acting as if that is likely to happen, worst-case thinking focuses only on the extreme but improbable risks and does a poor job at assessing outcomes." (from Schneier on Security)

I recommend you read Bruce Schneier's perspectives on worst-case thinking, it's quite interesting, and you will see his second and third reasons why we need to be careful with worst-case thinking.

Comment

Comment

How to Get Ready to Make Ballots

We've been spending a good chunk of our time lately on generating ballots, and on the steps leading up to ballot generation. You might think that the lead-up would be simple -- making lists of contests and candidates -- but actually there is lots more to it. In fact, it's been much more time consuming so far than the initial development of open source software to do the actual generation of PDF files with candidate names, bubbles to fill in, and so forth. You might ask why, but there isn't a short answer. Instead, what I can provide today is a pointer:  some wiki material that first defines a bunch of terms, and then outlines the process of pulling together everything you need to start generating ballots. I think that it was quite a surprise to most of us that it took over 2 dozen definitions just for starters! And of course at this relatively early stage, the story is not inclusive of a huge variety of election administration practices nationwide -- we have plenty of work to do with our stakeholders to refine and extend to where TrustTheVote "Election Event Management" module is broad enough to drive the Ballot Generator's capability beyond this current example, to where all those various ballot items are done right for that wide variety of locales.

-- EJS

PS: The ballot generation is pretty cool though! Here are couple of samples:

CA2006sampleOSDVCA2006sampleOSDVcs

Comment

Comment

Votes Lost & Found in Myrtle Beach

Election officials in Myrtle Beach, SC, noted the absence of about 260 votes in the recent election there. Fortunately, the votes were found, and the reason for the error discovered -- and both before the election was certified. It's a good thing that Myrtle Beach election officials were making their lists and checking them twice, because it's quite possible for the omission to have been overlooked until after the election was final. However, the story is a good illustration of how some technology design decisions create the scope for operator error. The basic story is that in one polling place, a poll worker made a mistake in the process of extracting electronic vote totals from a voting machine, using a removable data storage cartridge in a way that's similar to how you might use a USB flash drive to copy some files off of your PC. The problem, however, it that these particular voting machines are designed to be picky -- if you don't use the right cartridge the right way, the data is not copied, and is omitted from the supposedly complete vote totals compiled later (Also, it is not obvious to exhausted poll volunteers when this mistake occurs.)

You might ask, why so picky? Wouldn't it be better to record vote totals in a way that didn't depend on a poll worker not making mistakes at the end of an 18+ hour day? Well of course, put that way, yes. But when you look at the actual details of the way the iVotronic voting machines work, you can see that from a techie perspective, the design is not crazy -- right up to the V-8 moment of realizing that a consequence is that operator error results in lost votes. Those details are not technical, quite instructive, and well explained by voting technology expert Doug Jones:

The electronic cartridge (PEB) is used to initialize the machine in the morning, enable the machine for voting before each voter, and close down the machine in the evening.

In some jurisdictions, a polling place has multiple PEBs: a master PEB for opening and closing the polls, and another used for routine voting. When you do this, only the master PEB has the zero report and the vote totals on it. If you've got several iVotronics at the polling place, and you use a different PEB to close the polls on some of them, the master PEB won't have all the totals; then, when you upload it, you'll be missing votes from some machines.

This is an excellent example of a procedural error of the type that the voting systems could help defend against, but don't. It would be possible to write specs that lead to automatic detection of machines believed to have been deployed for which no totals have been reported. Sadly, we haven't got such behavior in our system specs, and as a result, we chalk such problems up to human error and let the voting system off the hook.

As you can see, once again the devil is in the details -- and thanks to Doug for the infernal info.

-- EJS

Comment

1 Comment

Arkansas E-Vote Flipping: Force 9 Gale?

It seems like e-voting snafus are like weather: there’salways a bit of a storm somewhere, and now and then you get a big one. Although we can thank our lucky stars that we haven’t had a real hurricane, an electronic equivalent of Florida in 2000, the recent Arkansas vote-flipping snafu might qualify as a force 9 gale.

And because this time it is clear the outcome of the race was also flipped, this case of Arkansas State House District 45 in 2008 might

1 Comment