High Stakes Testing
Another story from our efforts around the Zambia election.
We brought through a group of University of Zambia students together to select our team of data clerks for the election. There's always a lot of info that needs to get shoveled into the database from phone calls or paper sheets. College kids make a good pool to draw from for that rather tedious but indispensible task; they're smart, literate, and more likely to be experienced with computers. They're also easier to keep at work until 4 AM since it's a well-known fact that students do not actually sleep.
About 80 University of Zambia (UNZA, delightfully pronounced "ooonzah") students showed up to take a chance at working with the Civil Society Elections Coalition on the project. While there's a bit of money involved, for them there's a big draw in having this group on their CV and getting a certificate of participation from a well-regarded NGO.
The students were greeted by an intoductory speech with a stirring exhortation on the importance of elections and independent monitors. Most seemed pretty enthusiastic. After a bit of training, the test started. For the most part, though, it wasn't the students under the microscope - it was our data-management system.
Don't tell our young friends, but basically all of them who showed up passed. It's important to do an evaluation to make sure they are comfortable with computers, committed, and actually willing to show, but it ain't exactly rocket science.
I was a lot less blasé about the software.
While our developers are great and have done this before, their new system is rebuilt from the ground up with some pretty sophisticated (read: likey to break) browser-side code. In fact, it's largely done with HTML 5, which isn't even well-supported in most browsers yet; we had to run Chrome to make it work.
Unsurprisingly we did manage to find a bunch of glitches. While our coders did good work, there's no debugging like having 50 students doing things you never would have thought possible all at the same time. At one point the whole system locked up for 10 minutes - considering they were supposed to be hired on the basis of the number of entries they did in that a fixed window, I'm afraid the stress levels started to rocket up until we promised them make up time.
User-focused software design ain't usually the strong suit of a typical database developer. By watching the students as they fumbled with an unfamiliar system we were able to spot frequently-occuring mistakes or inefficiencies in workflow that the developer was able to address in the next revision. In the process, they also gained a lot of experience with the system and were ready to go on election day.
Postscript: on election day, the software behaved flawlessly.