I struck a nerve talking about feature flags 💀

Happy Halloween!

Over 150 people signed up for my talk, "The Software Industry's Dangerous Love Affair With Overproduction"! I wanted to give this talk because I've started noticing a few things coming up over and over:

• Everyone is obsessing over how productive they are with AI
• Folks are busier than ever
• Is the bottleneck different now that AI made code so fast
• Things aren't getting better
• And very quietly, there are whispers of folks getting overwhelmed

So I wanted to share what is going on through the lens of the waste of overproduction. Then, though, it begs the question, "What should we be focusing on?" So I added in how to use the theory of constraints to spot the most impactful place to improve your process.

Give it a watch, and reply with questions, reactions, or challenges.

Now, I made a claim in that talk that feature flags' origin was rooted in decoupling development from release so that development could happen without being burdened by release. This is a tool that exists to enable overproduction.

That struck a nerve.

Since giving that talk, I've had several conversations about feature flags specifically. I'll break down the three objections so far.

1. Feature flags can be used to help product see if the idea was good or not.

Yes, and this is the only useful case for them. Sadly, this almost never happens in the wild. In fact, this was brought up as a hypothetical. But yes, it is perfectly appropriate for a product to use feature flags to ship small MVPs or POCs and use flags to test against small segments of a market or A/B test them to see what investments should continue or not. These flags naturally expire as the product evolves or pivots.

2. Feature flags protect production from problems.

So this argument is based on the age-old problem of not being able to trust our process to produce functioning code and systems. Feature flags don't fix this, just defer it. This applies to the whole issue of production data being different. You designed your code to handle inputs a specific way. Prove it.

The fact that feature flags exist doesn't justify a low-quality process. It just helps you manage the symptoms of it.

3. Development, release, and deploy shouldn't be coupled.

Let me turn this around. You are building a feature that customers are waiting in line for. Actually waiting for. Why would you do anything other than ship it to them immediately? Let me make this less hypothetical. You have a hotfix. Do you decouple them then? No, you ship it immediately. You may be able to tune these independently, but when there is real demand, it's one step because everything else gets in the way. Everything else is a compromise due to quality or overproduction.

Now, I've been around the block enough to know how topics like this come across. I sound both right and crazy. The crazy part is there because very few of us have ever seen the possibility I'm hinting at. So I'm talking about something unrealistic for most folks. There are practical issues that exist that mean we can't get rid of feature flags.

Yet.

But it is absolutely possible to work without feature flags, complex release management, and code review and still ship code quickly and safely. That was true before AI, and I have no reason to believe it's different now.

Sincerely,

Ryan

PS: If you want to talk through this, schedule a chat or just reply.