Extend article on feature flag

2 files changed, 75 insertions, 6 deletions

diff --git a/_articles/2020-10-12-feature-flags-differences-between-backend-frontent-and-mobile.md b/_articles/2020-10-12-feature-flags-differences-between-backend-frontent-and-mobile.md
index 2f53295..d4bc066 100644
--- a/_articles/2020-10-12-feature-flags-differences-between-backend-frontent-and-mobile.md
+++ b/_articles/2020-10-12-feature-flags-differences-between-backend-frontent-and-mobile.md
@@ -8,21 +8,90 @@ category: presentation
 published: false
 ---
 
-*This article is derived from a [presentation][presentation].*
-
+*This article is derived from a [presentation][presentation] on the same
+subject.*
 
 When talking about [feature flags][feature-flags-article], I find that their
-costs and benefits weight very differently if applied backend, frontend or
-mobile, but those aren't always covered explicitly.
+costs and benefits are often well exposed and addressed. However the weight of those
+costs and benefits apply differently on backend, frontend or mobile, and those
+differences aren't covered.
 
 I'll try to make this distinction clear, with some final best practices I've
-acquired after using them.
+acquired when using them in production.
 
 [presentation]: {% link _slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides %}
 [feature-flags-article]: https://martinfowler.com/articles/feature-toggles.html
 
 ## Why feature flags
 
+Feature flags in general tend to be cited on the context of
+[continous deployment][cd]:
+
+> A: With continous deployment, you deploy to production automatically
+
+> B: But how do I handle deployment failures, partial features, *etc.*?
+
+> A: With techniques like canary, monitoring and alarms, feature flags, *etc.*
+
+Even though adopting continous deployment doesn't force you to use feature
+flags, it creates a demand for it. The inverse is also true: using feature flags
+on the code points you more obviously to continuous deployment.
+
+But you should consider feature flags solely by taking into account this
+distilled trade-off analysis:
+
+> Am I willing to pay with code complexity to get dynamicity?
+
+It is true that you can make the management of feature flags as
+straightforward as possible, but having no feature flags is simpler than having
+any. What you get in return is the ability to parameterize the behaviour of the
+application in runtime, without doing any code changes.
+
+Sometimes this added complexity may tilt the balance towards not using a feature
+flag, and sometimes the flexibility of changing behaviour on runtime absolutely
+is worth the added complexity. This can vary a lot by codebase, feature, but
+fundamentally by environment: its much cheaper to deploy a new version of a
+service than to release a new version of an app.
+
+[cd]: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
+
+## Rollout
+## Feature flag
+## Experiment
+## Operational toggle
+
+## Best practices
+
+### Prefer dynamic content
+
+Even though feature flags give you more dynamicity, they're still somewhat
+manual: you have to create one for a specific feature and change it by hand.
+
+If you find yourself manually updating a feature flags every other day, or
+tweaking the percentages frequently, consider making it fully dynamic. Try
+using a dataset that is generated automatically, or computing the content on the
+fly.
+
+Say you have a configuration screen with a list of options and sub-options, and
+you're trying to find how to better structure this list. Instead of using a
+feature flag for switching between 3 and 5 options, make it fully dynamic. This
+way you'll be able to perform other tests that you didn't plan, and get more
+flexibility out of it.
+
+### Use :include-list for named groups
+
+### Always use :app-version
+
+Don't delete app-facing feature flags
+
+### Beware of many nested feature flags
+
+### Include a feature flag on the whiteboarding phase
+
+### Include deleting/retiring the feature flag at the end
+
+### Always rely on a feature flag on the app
 
+There is no such thing as
 
 [apple]: http://www.paulgraham.com/apple.html
diff --git a/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides b/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides
index 7c78150..775f567 100644
--- a/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides
+++ b/_slides/2020-10-09-rollout-feature-flag-experiment-operational-toggle.slides
@@ -296,7 +296,7 @@ Use `:app-version` with `:min-version` instead
 
 # ***Always*** rely on a feature flag on the app
 
-Hot fixes and expedited releases is a thing of the past
+Never do a hot fix, avoid expedited releases at all costs
 
 ???