"They have literally … made zero changes on these machines," Wallach said. "The software we are running today here in Houston is exactly the software that [we] looked at in 2007."
"If the software was written in less than the most perfect possible way, then two things happening at the same time might step on each other's toes," Wallach said. In this case, while the machine is still populating the ballot with the straight-party votes, users are inadvertently touching the dial and pressing the "enter" button when the first page of the ballot containing the senate race is still loading. This causes the system to think they want to change the straight-party vote in that race to the opposite candidate, which is known as a cross-over vote.Hart InterCivic told the Dallas Morning News that its eSlate system is not at fault and that the system "simply records the voter’s inputs; it does not, and cannot, ‘flip’ or ‘switch’ votes."But a well-designed system should not accept input from the voter while the machine is still populating a ballot. Wallach said that writing code to avoid race conditions is one of the hardest things to do in programming and one that nearly all students and even professionals get wrong."While you're working on one part of the program, you have to be cognizant that this other thing might be happening at the same time. That is a very difficult thing to do, and as a result it's very error-prone," he told Motherboard. Nonetheless, he doesn't believe Hart InterCivic or state officials should be let off the hook because they've had a decade to fix the issue and have chosen not to.
"Ten years ago this was a known problem [with straight-party ballots]. And even then, years ago, we were told it was a usability problem"