3 ms·

Hi - we're a feature flagging platform. You can put new features that you are working on behind boolean flags and then manage those features from our dashboard.

rwmj 6y ago
Still unclear! "Feature" means a software feature? For example "I've implemented the feature of sorting customer records by date of birth"? I don't really understand why anyone would need a service to manage software features, so maybe feature means something else.
- dabeeeenster 6y ago
  We have an overview of why you might like to use a feature flagging platform here: https://docs.bullet-train.io/overview https://docs.bullet-train.io/overview Hopefully that helps!
  - kristopolous 6y ago
    This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality? I'll happily accept a "no you're crazy".
    - tashoecraft 6y ago
      This is used extensively. X customer wants to test y feature, but z customer is the middle of a large test and refuses to see c feature. Roll out feature to test client, slowly roll out feature to each client. Something to wrong? It’s incredibly fast to update the flags.
    - camnora 6y ago
      For smaller projects and teams, something like feature flagging can probably be avoided unless A/B testing is required. For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back. Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature). Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment. Like anything else in software, feature flagging can incur technical debt if not properly maintained.
- deleted 6y ago
  [deleted]
- dmitriid 6y ago
  Feature flags are used for gradual rollout and testing of features. Including, but not limited by, A/B tests, region-locking features, rolling to features to internal users only and so on. For example, you're developing a new version of the checkout page for your company from scratch (it can be a store selling physical goods, or a subscription service, or anything that requires payment). It means that for a while it will not have feature parity with your existing checkout page. So first you implement feature parity with, say, German payment options (credit cards and Sofort). Then you set up a feature flag saying "for 5% of German customers display the new checkout", and monitor it. Then you bump it up to 10%, then to 50%. Meanwhile you're working on accepting payments via Swish in the new checkout in Sweden. Once it's ready, you add a feature flag saying "for 5% Swedish customers display the new checkout" (and in parallel, you're probably already displaying the new checkout to 50% German customers). And so on. In their core feature flags are not really more than a glorified if statement, but: - you want to view them, and handle them in a single place so that you can adjust the various parameters or quickly shut down a feature if it misbehaves - this single place has to be scalable enough that it survives an influx of customers potentially triggering dozens of feature flags across your software

rwmj 6y ago

Still unclear! "Feature" means a software feature? For example "I've implemented the feature of sorting customer records by date of birth"? I don't really understand why anyone would need a service to manage software features, so maybe feature means something else.

dabeeeenster 6y ago
We have an overview of why you might like to use a feature flagging platform here: https://docs.bullet-train.io/overview https://docs.bullet-train.io/overview Hopefully that helps!
- kristopolous 6y ago
  This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality? I'll happily accept a "no you're crazy".
  - tashoecraft 6y ago
    This is used extensively. X customer wants to test y feature, but z customer is the middle of a large test and refuses to see c feature. Roll out feature to test client, slowly roll out feature to each client. Something to wrong? It’s incredibly fast to update the flags.
  - camnora 6y ago
    For smaller projects and teams, something like feature flagging can probably be avoided unless A/B testing is required. For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back. Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature). Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment. Like anything else in software, feature flagging can incur technical debt if not properly maintained.
deleted 6y ago
[deleted]
dmitriid 6y ago
Feature flags are used for gradual rollout and testing of features. Including, but not limited by, A/B tests, region-locking features, rolling to features to internal users only and so on. For example, you're developing a new version of the checkout page for your company from scratch (it can be a store selling physical goods, or a subscription service, or anything that requires payment). It means that for a while it will not have feature parity with your existing checkout page. So first you implement feature parity with, say, German payment options (credit cards and Sofort). Then you set up a feature flag saying "for 5% of German customers display the new checkout", and monitor it. Then you bump it up to 10%, then to 50%. Meanwhile you're working on accepting payments via Swish in the new checkout in Sweden. Once it's ready, you add a feature flag saying "for 5% Swedish customers display the new checkout" (and in parallel, you're probably already displaying the new checkout to 50% German customers). And so on. In their core feature flags are not really more than a glorified if statement, but: - you want to view them, and handle them in a single place so that you can adjust the various parameters or quickly shut down a feature if it misbehaves - this single place has to be scalable enough that it survives an influx of customers potentially triggering dozens of feature flags across your software