Tenured Radical is asking the question that should be required reading for every CIO, CTO, LMS suitor, and higher ed tech commentator: if computers are such a blessing to higher ed, how come their use is actively extending the working lives of their users to such a damaging degree? The series of events she describes will have elicited low moans of sympathy from all of us working in writing-intensive courses online: an innovative learning task set up to use a system well, driven by good teaching principles and student-centredness and all the rest of it, all going swimmingly until, with a clunk:
Students suddenly became unable to upload the papers that they were expected to share with each other for the following day. Since I became aware of the issue around 6 P.M., when the earliest finishers started trying to deposit their work, I ended up spending an evening on it that I would otherwise have spent preparing the class itself (of course, given that it was long after working hours, I would have preferred catching up with Boardwalk Empire, reading a novel or staring glassily into space.) No technophobe, I opened up the settings to see what was wrong, and there went the rest of the night, with a quick break to warm up something from Trader Joe’s. At one point, I found myself displaying the platform on three separate browsers to compare the settings that had worked to the settings that hadn’t, creating exact parallels between the settings on each browser, and testing each (as if I were a student) to see if what we were dealing with was a browser rather than a software issue.
You need to read the whole post to find out what went wrong and how it was eventually fixed, but the point that can’t be hammered home stridently enough is that this experience is … so … routine.
Something I think many university leaders find hard to grasp as they’re searching for the magical online cloud that will save them from the infrastructure costs of more buildings and services, is that clouds seem easier and quicker to establish, but they really don’t stay still for long. That’s what makes the metaphor so effective: these clouds are moving. Software is constantly being upgraded, and systems are constantly being patched. Each tiny fix and patch risks causing one part of the overall structure to fall out of love with another, a situation made far more acute by the fact that higher education institutions can’t for one second guarantee browser compatibility among their thousands of users. Meanwhile, security, storage and disaster recovery are exceptionally volatile areas of institutional risk: people who are bothering to spend their time engaged in malicious hacking aren’t going to wait for everyone to catch up calmly. It’s a jungle out there.
All this means that what looks like a stable system at the interface, both for your CEO and your average user, is in fact just how things are patched up today. Most of the situations like the one Tenured Radical describes result from one of these tiny background fixes that has a butterfly effect somewhere else in the ecosystem. And this is so often discovered only late at night, on weekends, when students work intensively and academics really should be advised not to try to use this time to catch up on a little online reading or class preparation because this is exactly how we get caught over and over with the emails of panic about assignments that won’t upload, systems that lock out or freeze, or content that won’t download or open.
The realisation that this level of failure is so routine has added to my thinking yesterday about the lack of real competitive energy in the higher education technology market. The leaden nature of contract timing means, frankly, that vendors have become used to being able to disappoint us. We’re locked in and they know it. So again, the significance of the recent wins that Phil Hill has tracked in the emerging LMS vendor market isn’t the size of the institution or the number of users, even though these are truly impressive: it’s the length of the contract, and the time it will take for that institution and its users to come back on the market. Until then, the vendor is more or less safe from the consequences of poor design, and incomplete or stalled development.
Sadly, the real cost of this is swiftly transferred onto the higher education institution trying to manage its own customer relations. Our IT departments are flat out with the running repairs, and not all of this is done in normal office hours, as the systems teams try to find the time of the week when they can take the whole thing down safely for a few hours. In too many cases, this is at 6am on a Sunday morning, but even with this effort and cost, they still can’t save the tech-friendly student-centred academic who’s up late on Sunday night trying to figure out and communicate Plan B to her frantic students.
Momentarily I’ve forgotten why it is that we have all become so used to this, and so accepting of it. If the bricks and mortar showed a similar pattern of instability, I’m not sure we’d go back into the building on Monday, would we?