UWFlow / rmc

Flow is a website that lets you plan courses with friends.
https://uwflow.com
MIT License
233 stars 73 forks source link

Remove MenloCourse #306

Open JGulbronson opened 7 years ago

JGulbronson commented 7 years ago

MenloCourse is from another time, where the reviews were used to bootstrap data for Flow.

Now, Flow likely has enough UserCourse objects to allow MenloCourse to be removed. The data is 3 years stale, and it would simplify the code.

Also, Menlo isn't an intuitive name :P

This could be done in 2 parts, with references to Menlo removed, and then the data deleted after a successful deploy.

JGulbronson commented 7 years ago

Okay, rethinking this. The data isn't updated dynamically, and the last dump is from almost 3 years ago.

Unfortunately, we rely on a lot of these reviews for professors. However, MenloCourse still has a course_review associated with it, which doesn't make much sense given where the data came from.

It seems the best path forward is to just comment what the class does, so that people don't try to use the course_review field. Dropping all MenloCourse objects might be disruptive to users, but potentially provide better data (or stop providing incorrect data, since it's so old).

Thoughts?

jswu commented 7 years ago

Disclaimer: I don't have much insight into what fraction of current reviews are Menlo vs UserCourse, and what the impact will be if we dropped Menlo

That being said, my inclination is to understand the value and cost of both decisions. Here's my (incomplete) view below:

Keeping Menlo: Value: More review information => potentially "better" product Cost: Confusing code (when people read the class), technical debt (having an extra object/concept in our system) => slower development velocity (which means slower to implement new futures in the future, which means "worse" product)

Remove Menlo: Value: Easier to write new code => higher velocity => build more features or bug more bugs => better product in the future (assuming we continue to furiously develop) Cost: Potentially worser product experience today.

I think that if we feel like the technical debt will non-trivially decrease product development (bug fixes, features, recruiting new contributors, etc) ability, and that we think we'll need this ability going forward, then I think we should get rid of it.

I guess this isn't too much of a concrete answer, but just more of my high-level decision framework. So practically, my questions are:

Is it's yes to any of the above, then I think we should definitely kill it.