This is why I prefer open source software. I can modify it
One person can use librsync to create a Dropbox company. Another person can use librsync for noncommercial purposes, e.g., to transfer and sync their own files
I mean... I, for my own needs, which are rather simple, can replace Dropbox with rsync. That's one thing. But yes, it's an entirely different thing to consider you don't need, or worse, could own, such business, on the simple premise you don't need it at your own level. That would be madness to mistake one for the other.
The data science is where the real value comes in. 10x flags changed this release - which one caused the improved CTR? Booleans as a service need to address this, and there are benefits to having your boolean service live next to your other services
It makes sense to not want to create an admin dash, but to avoid having to keep track of thousands of feature flags in your db, it seems all you're doing here is moving them to another db
Git is typically fairly slow if you have to wait on a test suite and deployment pipeline. Usually at least 10 minutes but sometimes 30, 60, 90+ minutes. A lot of purprose-built feature flag platforms hot reload the config in seconds.
JSON in the repo also risks introducing customer data to git if you want to rollout based on specific customer attributes (sometimes, for us, it's a list of early opt-in customers we have meetings with to discuss/develop new features)
It's also less accessible for "business users" like product/project managers, sales, and marketing they want to coordinate feature rollout with other business initiatives (and don't want to bother engineers when they do)
This gives you a distribution unrelated to active use, puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
Assuming you want a random distribution and don't want to take any other attributes into account.
We're a small company but new feature release for big features is typically targeted at low risk users/customers first. That usually means a few attributes are taken into account (age, customer value, customer sentiment, which features they use)
I’ve seen whole teams at companies set up fail to provide these booleans-as-a-service well. There are whole companies like LaunchDarkly for them.
If you boil it down to this, you may as well boil down every service that exists to bits-as-a-service.
Turns out theres legitimate business value in these things, and complexity in delivering them.
It's like saying Dropbox is just rsync.
IIRC Dropbox was originally created using librsync
Dropbox has modified it
https://github.com/dropbox/librsync
This is why I prefer open source software. I can modify it
One person can use librsync to create a Dropbox company. Another person can use librsync for noncommercial purposes, e.g., to transfer and sync their own files
Either way, it's librsync
I mean... I, for my own needs, which are rather simple, can replace Dropbox with rsync. That's one thing. But yes, it's an entirely different thing to consider you don't need, or worse, could own, such business, on the simple premise you don't need it at your own level. That would be madness to mistake one for the other.
The data science is where the real value comes in. 10x flags changed this release - which one caused the improved CTR? Booleans as a service need to address this, and there are benefits to having your boolean service live next to your other services
I don't mind it. I don't want to keep track of thousands of feature flags in my DB, have to create an admin dash, etc.
You could call any SaaS tool "excel-as-a-service" and it would hold the same power as your comment.
It makes sense to not want to create an admin dash, but to avoid having to keep track of thousands of feature flags in your db, it seems all you're doing here is moving them to another db
or maybe just make single JSON and commit it to git? your http server + GitHub + JSON and text editor is your admin ui, audit, etc.
Git is typically fairly slow if you have to wait on a test suite and deployment pipeline. Usually at least 10 minutes but sometimes 30, 60, 90+ minutes. A lot of purprose-built feature flag platforms hot reload the config in seconds.
JSON in the repo also risks introducing customer data to git if you want to rollout based on specific customer attributes (sometimes, for us, it's a list of early opt-in customers we have meetings with to discuss/develop new features)
It's also less accessible for "business users" like product/project managers, sales, and marketing they want to coordinate feature rollout with other business initiatives (and don't want to bother engineers when they do)
how would a single JSON allow staged rollouts with sticky sessions?
you pick a frequency you want, represent that as a fraction, and modulo on user id, and your 80% of the way there
This gives you a distribution unrelated to active use, puts users in the same bucket (with the same number you’re going to have the same users in the first 10%) and links combinations together.
Often problems are more complex than they seem at first sight and I have found it’s a good approach to think “what am I missing” rather than “lots of people must be making very obviously bad decisions” and reach the latter conclusion only after more work. Usually I’ve missed something.
This just tells me you haven’t worked on a big/complex enough system.
If it were that easy people would not be paying for it.
Assuming you want a random distribution and don't want to take any other attributes into account.
We're a small company but new feature release for big features is typically targeted at low risk users/customers first. That usually means a few attributes are taken into account (age, customer value, customer sentiment, which features they use)
Getting those booleans to the right place at the right time reliably isn't trivial.
MVP
yes, worth every penny
[dead]