[TeMPOraL]

> They lack knowledge and context about how to build production systems that handle the load during the registration crush and also don't cause undue load on the backend API servers.

That sounds like a cop-out. Sure, students may not know about all this, but they're also not building Google. Many people run businesses without caring about such things just fine. Most things don't require six nines of reliability and people don't expect them to be this reliable. Students in particular are used to university systems being constantly down, or resource-starved to the point of uselessness for no good reason.

> it's often easy to come up with a naive solution without understanding the context, that kind of works but that actually makes things overall worse. For example, what if your app crashed the registration backends during the middle of registration. Are you, the clever student, on call during registration (24/7) for your app, and in contact with the folks who run the registration backends?

It's hard to come up with a solution that's worse than what you get at universities for this stuff, which usually is nothing at all - and even if it is something, there's no one on call to help the student anyway.

[croemer]

I got their code to run and it's not good. It's unusable as is and could be created from scratch in a better way in a day. It lacks all integrations with the University API, that part was never written.

The existing matching of swap requests is poorly done and requires much further work.

There's nothing of value here that OP had to scuttle.

[dekhn]

Yes, but as we know, the best way to make a project that is late/slow/unreliable even later, slower, and more unreliable is to add inexperienced devs to the project. Which is (from the perspective of the university) what they are trying to avoid.

[mrmanner]

well except they allegedly asked said allegedly inexperienced developer to develop the thing for them, for free

[dekhn]

Yes, I think this post has established that whomever created the response to the original ToS violation (rather, just a plan to violate the ToS) wasn't being very thoughtful (assuming everything is being described correctly). I would assume that at this point, the discussion has been moved above the original employee who responded and is being dealt with at the dean level (with the goal to be avoiding UW appearing in a bad light in the press).

I've seen hundreds of "administration outrage" articles and I guess I've kind of learned that the backstory is usually more complicated, nuanced, and reasonable than the original poster implied. But the internet mobs proceed anyway.