I wasn't really commenting on the social aspects of advance voting as much as the software and process wise. It certainly sounds much more challenging than the Iowa software issues. I mean, what was the challenge in Iowa -- submitting 3 pieces of data for 5 or 6 candidates? What Fortune 30,000 business with multi-site financial results doesn't do that daily, weekly or at minimum monthly for 10 to 1000X that data load? And they had to go out and find somebody to program that capability from scratch?
In Nevada you need to communicate XX number of individual force-ranked ballots so that each precinct can combine counts, test for viability and then execute a re-roll of the forced ranking votes and re-consolidate the counts.
And although the article doesn't discuss it much, all of this has to be integrated with the precinct master roles to preclude duplicate voting, or more likely, a caususer who wants to change their early vote on the day of the caucus. Generally in early vote states a voter who shows up on election day signs the voter log and votes, and that vote pre-empts any advance ballot as they are counted and compared to the master role after election day. What's Nevada going to do -- presumably they will have to identify the early voter PIN and cancel the early ballot so it doesn't execute. Got to do that real time, because of the viability re-distribution. And if that is the case, if the local official has the process capability to suspend or cancel an advance vote on their I-pad, from an auditor standpoint, that just opens up monstrous vote integrity issues -- especially with a viability redistribution function ready to roll. Cancel two votes and redistribute 12% of the vote?
I just look at all the possible, obvious process pinch points and just roll my eyes. You want early voting, fine, but trying to merge it into a caucus environment with viability thresholds makes me just shake my head. But they're not my party.