RM Flags

Hey Product Hunt! Excited for you to check out my newest product, RM Flags. Some context on why I built this: When I worked at a big tech company, there was a massive push to get all developers using feature flags and experimentation to improve the product’s uptime and increase customer trust (there had been a lot of outages and customers were churning due to this). Once we started using feature flags, I noticed some distinct advantages: 1. Being able to slowly roll out a feature to a subset of users was powerful for testing and end-to-end verification. 2. It enabled “testing in production”: instead of wasting money deploying an entire staging environment, we could now just ship features “dark” (0% rollout) and then enable just our test user ids to verify the feature if our automated tests weren’t enough. 3. Being able to roll a single broken feature back to 0% with a button click meant that whenever outages did occur, they only affected a small % of users and were able to be mitigated immediately. This was a lot better than the usual cycle of “oh no, someone shipped a critical bug in this release train, time to roll back the entire deployment” panic that used to ensue and take a full hour (we had a large codebase that took forever to build). However, I also noticed some downsides as they related to developer productivity: 1. Feature flags needed to be coded manually, so code ended up being littered with `if (featureFlag.isEnabled()) { ... } else if (someOtherFeature.isEnabled()) { ... } else { ... } }` blocks. With multiple feature flags in play, I found that this sort of pattern greatly complicated the code and made it harder to read (to know how the code will behave, you have to know which features are enabled which requires opening a browser and checking some config, then context switching back to the code) 2. Due to ruthless prioritization and the need to build new product features, developers were often not given the time needed to go back and remove the feature flag from the code when their feature had already been rolled out to 100% and verified, so the clutter I mentioned above never disappeared. 3. Ironically, I noticed that a new class of bugs appeared due to the above issues: code blocks became harder to read/understand due to the clutter, so the likelihood of someone not understanding the full extent of the code block increased which then led to various incidents that possibly wouldn’t have happened had feature flags not been applied in the first place. I decided to build RMFlags to solve these pain points by automating the removal of feature flags - it’s able to parse and understand code in any programming language, then change the structure of the code to remove the if blocks mentioned above. It’ll even automate the process of creating a PR with the changes so a developer can review. Normally, a developer would have to spend an hour cleaning up the codepath and updating tests to no longer reference the feature flag. With RMFlags, the time required to clean up a flag is greatly reduced as the only thing the developer needs to do is approve the PR and click Merge. Of course, the process isn’t perfect yet so some minor edits to the code may be required in the same PR. Check it out and let me know what you think! Thanks again.

Hey @ben_makes_stuff, I was thoroughly impressed by RM Flags' innovation in automating feature flag removal. It seems like a boon for developers, enhancing their productivity by streamlining code cleanup. I'm quite intrigued about how RM Flags parses code in any programming language. Can you elaborate more on this unique capability? Also, any plans to integrate it with popular development platforms for greater accessibility? Great work! 👍

Great!!!!!

Man I’ve literally had this exact problem! Always wondered if I could come up with a good solution, but looks like you have so kudos to you! Looks super cool :)

I've gotten a bit of feedback that people are unsure what's meant by a "stale" feature flag. Just to clarify, when you have a feature flag that you've already rolled out to 100%, you no longer need to reference it in your codebase -> it's now considered "stale" and can be removed safely. This is what RM Flags helps with! I've added a FAQ to the landing page about that as well.

I don't think this is a good idea, lol. Is this expected to run locally during development or what are the use cases? Hopefully this isn't doing some dynamic stuff in production.

It's so cool! It's a big pain point in big tech company. When we use AB Test, I need to write a lot of similar code.Code becomes difficult to maintain as it grows in size and complexity.This is a great tool for this problem.