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.

The scenario

Two status that can be assigned to an end user: 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

The status and when it changed is stored in a specific table in our database

Disapproved will now have a few restrictions in usage and continue the "invisibility mode"

Quickly implement the needed changes

What about the users that were disapproved in the past 6 years?

The options

Make new restrictions only available for users that are disapproved starting from a certain date

Go through each user and understand whom should keep the disapproved status, now with the new set of restrictions

Fast & easy

Disapproved now has two different meanings: one before the date it goes live and another after

That meaning is hidden in the code (don't get me started on documentation...)

Random logic deciding if users have the new set of restrictions or not

Data will mirror the current state of affairs

It can help uncover other issues that lead to a better solution. eg: having more than Approved and Disapproved

Who the hell wants to analyse a spreadsheet row by row?

Slower than #1

It might come to a place where hard decisions must be made. eg: choosing between continue user x disapproved or not and therefore ruin the user experience

The final decision

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 :)