[dekhn]

Yeah, let me give some perspective here.

There's somebody in the registrar's office whose job is to be responsible for the production process of registration. They are minimally staffed and given just enough resources to run that process. Likely at some point their leadership told them they had to make an API so that they could integrate with other systems. Due to poor funding and lack of skills, just doing that is a full time/major job.

Then some student comes along and says "hey look if I scrape this API, I can make an app that helps users! That's what APIs are for, right!?" The student is likely quite smart and probably built something that is useful.

But students aren't full time software engineers. 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.

So when the dean comes to the head of IT for Registration, and says "wait, this student just did something that you were supposed to do, and it looked really easy", you just made the IT person's life much harder but didn't actually necessarily solve the problem. Now the IT person has to defend what they have done, while looking bad... and is not getting any further resources to fix the issue.

I think this is a variant of the "why don't you just..." and chesterton's fence. That is, if you're inexperienced, 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 easy to criticize the IT folks at Colleges but they are not resourced to handle things like this.

[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.

[mmooss]

You write as if you've had some experience .... Still, the IT team should have reached out to the student - it's a university and they especially should be good and dealing with inexperienced, well-meaning students - and straightened it out: Hey, this is a great idea; it will also need this and this and something like this to work with these other systems and handle the load on registration day.

[lastdong]

It's really noteworthy that other students have the opportunity to engage in this and other projects as part of their curriculum. They can gain valuable experience while also contributing to the college community. It's disheartening that this situation has led to such drastic measures, impacting students' futures. It seems like there could have been more thoughtful ways to address this on the college's part.

[dekhn]

I am not sure I consider the university's production registration system as a useful project for students to contribute to. Those are systems that are the responsbility of the university administration, not the educational mission of the university.

Yes, the university was drastic; if I were the person responsible, I wouldn't have started with a terms of service violation and putting registration on hold; I'd write a nice thank you note with some encouragement, along with a direct request to hold off running the application until the next registration season, and a calendar entry to discuss this in person/off the written record to explain the more subtle aspects associated with developing production applications in a university environment.

[phibz]

> Yeah, let me give some perspective here.

This is spot on and way more likely than my contrived example. The point holds this is political as all things are in University environments.

Another interesting observation I made from my time working at a University is that it was one of the most toxic and political work environments I've ever had the displeasure to work in.

[nicky0]

APIs are not scraped. Web sites are scraped. APIs are simply used.