22
Fix your data, not your code
The exciting moment of starting an app from scratch is to know that you can do everything right. You'll have your CRUD operations very well thought out and ensuring that any database request is done properly, with the right data and at the right time.
Well at least, it's how I like to think about it and even though that should be fairly common, the world changes and data that was correct at the time might now be incorrect. Also it's not every day that you start an app from scratch.
Data quality plays an important role in the functioning of your application, furthermore if you have a high volume of end users using your app daily.
This blog post will quickly go through an use case that a team had to deal with recently where the decision was to fix the data and not the code
It's 2015
Approved
or Disapproved
-
Approved
: use the app with no restrictions -
Disapproved
: use the app with no restrictions but you are not part of the user listings
It's 2021
Disapproved
will now have a few restrictions in usage and continue the "invisibility mode"But the question arises
What about the users that were disapproved in the past 6 years?
Pros of #1
Cons of #1
Disapproved
now has two different meanings: one before the date it goes live and another afterPros of #2
Approved
and Disapproved
Cons of #2
In the end we went ahead with second option. While it took a while to review all the users and make the decision which ones should be under the new changes, we do believe that in the long run not having random decisions in the code (if statements checking and comparing dates, just because) will allows us to have a better product and happier developers.
This is my first post at dev.to, which has been a long time coming.
Hoping this can help someone out there :)
Hoping this can help someone out there :)