Newsletter: Feature flag mistakes to avoid #10302
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
As is tradition, I only have title-y type feedback. I think it's a bit dry - can we try something like 'Feature flag mistakes we've made at PostHog' (and how you can avoid them) or 'Non-obvious feature flag mistakes to avoid'? Not super helpful, but the first one 'not using them' just feels a classic clickbaity/listicle item. But I don't have something helpful to suggest to improve this so maybe it's fine! |
|
The option "Feature flag mistakes to avoid" was the highest voted option in a newsletter poll we ran FYI. |
There was a problem hiding this comment.
This is tight and very actionable. Additional high-level thoughts:
-
I think, in the intro, we need to connect using feature flags with our broader theme of product engineering. You kind of touch on it, but it should be super explicit that mastering feature flags is a key skill in becoming a good product engineer. I think you could probably start there – i.e. "We're always banging about how product engineers need to XYZ XYZ and feature flags are a key too."
-
Agree with Charles the headline. I view the polls as more topic testing than headline testing. We don't need to go crazy here, but it could do with a little something extra.
|
|
||
| The core of a feature flag's value to developers is the ability to turn them off. They need to be ready for this at any point, which isn't always the case. | ||
|
|
||
|  |
There was a problem hiding this comment.
I think this would be a good one to turn into a Maxhog meme – I'm sure Lottie could dress Max in the pikachu costume! We could use this as the main image.
Co-authored-by: Bijan Boustani <[email protected]>
|
ok, title and intro updated |
|
|
||
| Product engineers succeed when they can ship quickly, understand if a change is working, and iterate from there. Because they let you ship, deploy, and release software safely, [feature flags](/feature-flags) are a powerful tool for doing this. | ||
|
|
||
| But with great power comes great responsibility. Misused feature flags have caused downtime for the largest apps in the world, created a mountain of tech debt, and nearly bankrupted a company (we'll cover this later). Luckily, these are all avoidable mistakes we can learn from and avoid. |
There was a problem hiding this comment.
fwiw, I kinda feel like the "great power etc" line is a bit tired these days. maybe come up with something else here?
| Before I tell you the ways flags can go wrong, let me start by saying that the biggest potential mistake of them all is **not using feature flags**. | ||
|
|
||
| At [PostHog](/feature-flags) (and many other companies), they provide two main benefits: | ||
|
|
||
| 1. **Safety.** Flags enable progressive rollouts and kill switch rollbacks enabling you to deploy and release new code safely. | ||
|
|
||
| 2. **Speed.** By [separating deployment from release](/product-engineers/decouple-deployment-from-release), they enable us to do [trunk-based development](/product-engineers/trunk-based-development) meaning we can [ship more changes faster](https://newsletter.posthog.com/p/how-to-design-your-company-for-speed). | ||
|
|
||
| On top of this, they let us run [A/B tests](/experiments), [beta programs](/tutorials/public-beta-program), and [dogfood](/product-engineers/dogfooding) our changes. As a [remote and async team](https://newsletter.posthog.com/p/how-we-work-asynchronously), this is critical to our success. Our tactics for developing and releasing software would be a lot more limited without them. |
There was a problem hiding this comment.
-
This is a bit of a nit, but I think this section should talk more about the benefits to "you" (the reader) rather than us. We can still talk about how we use them, obviously.
-
Random thought: Should we try this as the last point? I feel like the "let me start by saying that the biggest potential mistake of them all is **not using feature flags" kind of takes me out of the article a bit. This might work better there.
There was a problem hiding this comment.
Yeah, I debated this and since multiple people have commented on it, I will try it out
| - **Have poor searchability.** Generic or inconsistent names require more overhead to figure out and harder to find in a codebase. | ||
| - **Have unclear functionality.** Just looking at a flag name should give you some idea if it is used in an experiment, configuration, or release. The name should also hint whether it returns a string, array, or boolean. | ||
|
|
||
| ### What does a good name look like? |
There was a problem hiding this comment.
I suspect you can lose this heading. kind of ruins the pacing a bit, imo
Co-authored-by: Andy Vandervell <[email protected]>
Changes
Draft of a feature flag mistakes to avoid newsletter. Would love feedback on:
Closes: #9485
Checklist
Article checklist