February 4, 2020
It’s noon on the day after the Iowa caucuses, and we have yet to know who “won” thanks to a snafu with a smartphone app. Officials in Iowa have announced they’ll have an announcement by 5 pm.
Politics notwithstanding, I’m sure we’ll learn in the days to come more about the app, it’s developer Shadow, and what exactly went wrong. On its face, though it appears to relate to issues of (a) sufficient training, (b) understanding their intended user base, and (c) stress-testing of their SQL server back end.
In my experience, User Training is always given insufficient resources up-front — think of almost any tech product you’ve used, from any vendor, and how the user documentation and training always is a step behind the product. The feature sets are frozen prior to release, and THEN the Doc team tries mightily to get the training materials built and delivered. I salute those folks.
To be sure though, one of the great benefits of being a part of an app infrastructure is a common core of features and behaviors, which, developers will tell you, minimizes the training requirement.
The whole thing reminds me of a GREAT PLAN we had at the University of Tulsa to onboard all incoming Freshman to our VAX1 VMS mini-mainframe back in 1993.
The year before TU had completed a campus fiber optic loop, installed an SMTP gateway to our VMS system and started layering on additional, Internet apps. KU (Lou Montulli) had built Lynx: an early character-based web browser for VMS, Wisconsin had Gopher, and others were being ported free for academic use.
I’ve written before about what a heady time it was…I’ll refer you to that for more details.
Back at TU: students were taking to it, faculty were starting to count on it (both for their own scholarship and also to provide another vector for student communication) and rather than the organic training that happened student-to-student in the computer labs, it was decided that next August, during Orientation Week, we would break the incoming freshmen (around 300 if memory serves) into cadres of 20 or so. I and my colleagues in Client Services would have these cadres visit each campus computer lab at the same time in their tours, for assignment of usernames and initial passwords. Then we’d help them log on and begin to explore our “basic” level of Internet connectivity. We would run these presentations FIVE TIMES essentially back to back, at the three public computer labs on campus with DEC VT100 terminals, or enough machines with Ethernet connections (486 PCs, as the first Pentiums had just rolled out in the Spring!)
We had practiced and rehearsed our presentations, gotten all the login credentials from Zink Hall, and helped everyone enter their usernames and passwords, and hit ENTER.
At the same time.
At this point, the mainframe crashed.
Around 60 simultaneous logins killed it.
We realized immediately our folly, began tap-dancing and modifying the order of our presentation to save that first session.
While we waited for the folks in the basement of Zink Hall to bring things back up, we quickly agreed that in the next four sessions, each lab would alter their presentation: Chapman Hall trainees would all hit Enter at 10 minutes past the hour, Keplinger Hall at 15 minutes past, and Zink at 20 minutes past. Each lab’s content was hastily modified (no PowerPoints, just scripts and oration) to accommodate our new-found wisdom.
The famous Peter Drucker quote: “Culture eats Strategy for Breakfast” reminds me that, our IT culture at the time was not geared towards the mass-consumption of tech. As such, we did not have this experience to consider that even 60 simultaneous logins would be detrimental. The “bandwidth” if you will of a single terminal session login is not a lot, but 60 at the same exact minute requires tons more horsepower.
Our client-centric strategy was on the menu.
We learned and had beefed up our resources by the next Fall. Much as I’m sure Iowa will by 2024…
