PLEASE don't do this. I've worked on too many systems where these optional keys ended up being relied upon, misspelled, missing, unexpectedly null, etc. and a raft of bugs that made customers very unhappy necessitating a time consuming "data cleanse".
Use a system which makes it easy to do migrations instead. It will take barely any longer to create that new column and it won't store up trouble in the future.
As an industry, software development needs to get better at cleaning up TODOs. This is especially bad when business needs take prime spot always. Sometimes, technical health needs to take priority and drive down these issues. If there’s confidence in the organization that we can take on some tech debt and pay it down a little bit later, then you can move faster (just like leverage in finances). It’s when the debt you take on is so great or so well swept under the rug that it turns into a monster and ruins your day. If the tech debt items are allowed to live forever, the org gets into the position of quickly maxing out their credit and never being able to add more debt which slows delivery.
In the scrum world, prioritizing a feature story over a debt story should require a strong reason with significant debate. Don’t let them live longer than a couple of sprints.
I don't think there is any substitute for experience in this matter. Some hacks are fine to last essentially forever, some should never be allowed to happen and others are probably ok but only if they get unwound in under a week. It's rarely obvious which ones are which until you've felt the pain.
I tend to believe that hacks that undermine the integrity of your data are the absolute worst (which is why my reaction to this was so visceral) but can sense I might just be a product of my environment - different industries and use cases vary quite wildly in their expectations of quality and attitudes to failure.
Agree about Scrum. It creates a very high cost to unwind any tech debt that can't be smuggled into a story.
Same camp here, even more if this is a startup, these once-optional keys and settings will be ossified into the database, the knowledge of why they existed will be lost (as most knowledge from startups after 5 years end up), untangling that mess will take an engineer's days to weeks doing discovery work of possible incantations of its usage, etc.
If you give such a powerful feature to any table you are just shooting yourself on the foot on the whole modeling of your application, there is no static representation of the model, it will be dynamic depending on the JSONB configuration.
I totally understand where you're coming from. I think the greatest issue is when there's an overlap between two things:
- the fact that systems like Django actually make it difficult to switch branches from a feature branch with one migration to another on a different migration tree, without fully rolling back everything (including the test data you may be deep in the weeds experimenting on, that may not yet be in fixtures), and
- being in an environment where you require same-day turnaround on things that aren't really bugs but would be seen that way by high-profile clients, and the priority is high enough to disrupt flow and run the risk of those "raft of bugs"
For instance, if User A is highly influential and it would be meaningful to the business to have rapid turnaround on ensuring that Asset B that they're looking at has a specific fix to some data that you know you should make fully customizable at users' discretion, but don't yet have the right spec in place to build a customization on a per-Asset basis, and every team member is deeply working on debugging a feature... you just do asset.config.foo = bar, ensure it's extremely well documented at the site where a column definition would be in your model file, make a simple commit that you know won't affect anything else, and you take that as technical debt, and you keep yourself from getting too far out of flow.
The "data cleanse" you speak of comes in the form of a regular inventory of live config variables (select the set of keys and distinct values across all configurable tables), and the creation of user stories where necessary.
If there was a way to `git stash` all changes made to a dev database, and pop that afterwards, that would absolutely make it possible to do a more robust workflow. It's ironic that e.g. Postgres MVVC and transactional DDL is so robust, and yet I haven't found a tool that makes it feel nearly as seamless.
Use a system which makes it easy to do migrations instead. It will take barely any longer to create that new column and it won't store up trouble in the future.