Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Remove MenloCourse #306

Open
JGulbronson opened this issue Nov 18, 2016 · 2 comments
Open

Remove MenloCourse #306

JGulbronson opened this issue Nov 18, 2016 · 2 comments

Comments

@JGulbronson
Copy link
Member

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
Copy link
Member Author

JGulbronson commented Nov 18, 2016

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
Copy link
Member

jswu commented Nov 26, 2016

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:

  • Will this tech debt prevent us from fixing bugs more/faster? Is this specific issue (Menlo) a bottleneck for this point (fixing bugs)?
  • Will this tech debt prevent us from building more features [faster]? Is this specific issue a bottleneck for this point (building features)?
  • Will this tech debt prevent us from recruiting more contributors? Is this specific a bottleneck for this point (recruiting contributors)?

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants