No mystery to a programmer. (No excuse, either, but...)
The computer wasn't programmed to count down. That's just the way a computer will work when someone tries to add one more to a counter that is so at its maximum value.
Remember that computers use binary (base-2) numbers, not decimal (base-10) as we do. Imagine a car odometer that is at 999999 and you add one more mile. It will roll over to 000000. Oops.
Similarly, a 16-digit binary number is not uncommon on older hardware and it turns out that this means it will roll over at 32,768 (which is 2^15). Exactly what happens at that point can vary based on hardware, but one possibility is that it rolls over to 0, but then starts counting negative (-1, -2, -3, ...).
Which sounds suspiciously like what happened here.
The problem is that a programmer: 1) used a counter that is too small for the task at hand, and 2) did not check to see if the counter was at its maximum before trying to add one more to it.
Example: the computer reads a value of 25,000. We know that's bogus. We also know it was 'down-counting'. Therefore, the 32,768th ballot would show 32,766 on the meter; the next one shows 32,765, and so on.
Extrapolating this gives an actual count of 40,535. And given the uncertainty of things, I'd still call that +/- 2 votes. but of course there's no way anyone would ever certify such a calculation.
not signed int VoteTotal;
unsigned int VoteTotal;
/* dammit!! */