Simon Willison’s Weblog

Subscribe
Atom feed for feature-flags

9 items tagged “feature-flags”

2025

Hacker News conversation on feature flags. I posted the following comment in a thread on Hacker News about feature flags, in response to this article It’s OK to hardcode feature flags. This kicked off a very high quality conversation on build-vs-buy and running feature flags at scale involving a bunch of very experienced and knowledgeable people. I recommend reading the comments.

The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot.

I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change and using an (often expensive) feature flags as a service platform: roll your own simple system.

A relational database lookup against primary keys in a table with a dozen records is effectively free. Heck, load the entire collection at the start of each request - through a short lived cache if your profiling says that would help.

Once you start getting more complicated (flags enabled for specific users etc) you should consider build-vs-buy more seriously, but for the most basic version you really can have no-deploy-changes at minimal cost with minimal effort.

There are probably good open source libraries you can use here too, though I haven't gone looking for any in the last five years.

# 2nd February 2025, 1:18 am / hacker-news, feature-flags

2024

How I ship projects at big tech companies (via) This piece by Sean Goedecke on shipping features at larger tech companies is fantastic.

Why do so many engineers think shipping is easy? I know it sounds extreme, but I think many engineers do not understand what shipping even is inside a large tech company. What does it mean to ship? It does not mean deploying code or even making a feature available to users. Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.

Sean emphasizes communication, building confidence and gaining trust and the importance of deploying previews of the feature (for example using feature flags) as early as possible to get that crucial internal buy-in and feedback from other teams.

I think a lot of engineers hold off on deploys essentially out of fear. If you want to ship, you need to do the exact opposite: you need to deploy as much as you can as early as possible, and you need to do the scariest changes as early as you can possibly do them. Remember that you have the most end-to-end context on the project, which means you should be the least scared of scary changes.

# 11th November 2024, 11:54 pm / software-engineering, management, feature-flags

We used this model [periodically transmitting configuration to different hosts] to distribute translations, feature flags, configuration, search indexes, etc at Airbnb. But instead of SQLite we used Sparkey, a KV file format developed by Spotify. In early years there was a Cron job on every box that pulled that service’s thingies; then once we switched to Kubernetes we used a daemonset & host tagging (taints?) to pull a variety of thingies to each host and then ensure the services that use the thingies only ran on the hosts that had the thingies.

Jake Teton-Landis

# 25th September 2024, 6:08 pm / feature-flags, baked-data, sqlite, kubernetes

2023

At The Guardian we had a pretty direct way to fix this [the problem of zombie feature flags]: experiments were associated with expiry dates, and if your team's experiments expired the build system simply wouldn't process your jobs without outside intervention. Seems harsh, but I've found with many orgs the only way to fix negative externalities in a shared codebase is a tool that says "you broke your promises, now we break your builds".

jbreckmckye

# 10th July 2023, 6:53 pm / feature-flags, continuous-integration

2021

Product Hunt Engineering Principles (via) Product Hunt implement “Collaborative Single Player Mode”, which they define as “A developer should be able to execute a feature from start to finish -- from the database to the backend, API, frontend, and CSS. The goal is never to get blocked.” I’ve encountered this principle applied to teams before (which I really like) but not for individual developers, which I imagine is more likely to work well for smaller organizations. Intriguing approach.

They also practice trunk driven development with feature flags: “Always start a feature with a feature flag and try to get something to production on day 1.”

And “If a product decision is missing, try to make this decision yourself—it’s better to ask for forgiveness rather than permission.”

# 16th August 2021, 3:35 pm / management, feature-flags

2020

How we use “ship small” to rapidly build new features at GitHub (via) Useful insight into how GitHub develop new features. They make aggressive use of feature flags, shipping a rough skeleton of a new feature to production as early as possible and actively soliciting feedback from other employees as they iterate on the feature. They static JSON mocks of APIs to unblock their frontend engineers and iterate on the necessary data structures while the real backend is bring implemented.

# 2nd January 2020, 4:30 am / deployment, feature-flags, github

2019

Feature Toggles (aka Feature Flags). I’m a huge fan of feature flags as a way of managing feature releases and keeping incomplete code in master as opposed to maintaining long-running branches. Recently I’ve found myself pointing people to this essay by Pete Hodgson—it’s a great overview of feature flags (here called toggles) and I particularly like how it splits them into four categories: Release Toggles, Experiment Toggles, Ops Toggles and Permissioning Toggles.

# 25th June 2019, 9:13 pm / feature-flags

2014

Feature Flags, from PyCon 2014. Slides from a 15 minute talk I gave at PyCon 2014 about feature flags - what they are, how to use them and how we implemented them at both Lanyrd and Eventbrite.

This was part of a longer workshop on Advanced Django Patterns from Eventbrite and Lanyrd, which I co-presented with Andrew Godwin and Nathan Yergler.

# 10th April 2014, 6:27 pm / pycon, python, django, feature-flags, speaking

2010

How we deploy new features. GitHub are experimenting with using Redis for configuration management. I’ve been thinking about this recently too—managing feature flags feels like an ideal use-case for Redis, since it lets you read multiple values on every page access without adding a bunch of extra read traffic on your regular database.

# 8th July 2010, 10:04 am / github, redis, recovered, feature-flags