You shouldn't be surprised at all. The schools don't build these things - they buy generally large-scale systems that claim to do X things, but mainly perform a smaller percentage of X things competently, leaving other features slow/broken. But with only a relatively small handful of customers out there, and a generally long sales cycle, its primarily larger vendors who can engage with customers like universities, and smaller companies which are able to provide innovative functionality often don't get to market.
I've built a registration system for a moderately large school district - it handles about 20,000 students per semester, and while it's certainly not simple to handle everything that's needed, it's not that hard to make something perform decently enough. At peak, we have hundreds of people checking or making enrollments concurrently, which always involves doing waitlist checking (and, IIRC, different waitlist policies apply to different student types and courses). All of this is standard HTML interface - if we were to build an API to serve up just raw JSON, the load would likely be a bit less.
Back to the surprise - schools are mostly just businesses - they generally outsource their foodservice too - it'd be great if there was a lot more home cooking on most campuses, but they're often overrun with processed foods. Same thing with a lot of software infrastructure - it's outsourced/off-the-shelf stuff vs stuff built with on-campus skills. Faculty/staff/students developing more campus/school-related stuff could be a game changer, no? Is the idea that most of those students won't be there in 2-4 years a big hindrance to this approach?
"Is the idea that most of those students won't be there in 2-4 years a big hindrance to this approach?"
Yes. That's always the excuse in my experience, even when it doesn't make any sense. At my previous university job, my department used an ancient—and I really mean ancient—shopping cart system. This thing had been written in ColdFusion during the mid-90s and they were still running it in 2009. It required all kinds of hand-holding and manual labor that should've otherwise been automated. Even though the original (outsourced) developer had long since disappeared, management refused to consider a new shopping cart. Why?
"Because we can't risk losing the person who sets it up."
There are no words. I chalk up the attitude to extreme, unhealthy risk-aversion.
I wish more people were required to take a logic course before getting to work at a university.
They've already lost the person who set it up - there's zero "risk" involved - it already happened. The world didn't end. But life is painful for many people because of the current system.
I've built a registration system for a moderately large school district - it handles about 20,000 students per semester, and while it's certainly not simple to handle everything that's needed, it's not that hard to make something perform decently enough. At peak, we have hundreds of people checking or making enrollments concurrently, which always involves doing waitlist checking (and, IIRC, different waitlist policies apply to different student types and courses). All of this is standard HTML interface - if we were to build an API to serve up just raw JSON, the load would likely be a bit less.
Back to the surprise - schools are mostly just businesses - they generally outsource their foodservice too - it'd be great if there was a lot more home cooking on most campuses, but they're often overrun with processed foods. Same thing with a lot of software infrastructure - it's outsourced/off-the-shelf stuff vs stuff built with on-campus skills. Faculty/staff/students developing more campus/school-related stuff could be a game changer, no? Is the idea that most of those students won't be there in 2-4 years a big hindrance to this approach?