OK, let's unpack this. So if you're building software
today, you've got this, this fundamental tension, right?
Businesses are demanding constant updates, daily
deployments, maybe even more. But the code going in, it's
often half baked, untested, potentially really broken.
Yeah, it's that classic clash speed versus stability.
You want continuous deployment, that ability to just push
features out instantly. But if you're doing things like
trunk based development, everyone emerging code all the
time into the main branch, well, things get unstable fast.
How do you stop that new feature?
Let's call it Feature X, the one that's not quite ready from
hitting customers? Right.
And that tension, it used to be a huge headache the old way.
And the sources are pretty clear.
This is the way anymore. I was, I know, keeping your code
totally separate on a branch for weeks, months, sometimes waiting
until it was absolutely, positively perfect before
merging. Which led straight into what?
Developers absolutely hate integration hell or merge hell.
You know, spending days, maybe weeks, just fighting with code
conflicts because everything's diverged so much.
You basically threw out continuous integration just to
avoid deployment risk and well, that's just not sustainable now.
OK. So continuous integration is non
negotiable. We need it.
So we need some kind of technical tricks, something to
split the risk apart and that right there, that's what we're
diving into today. Feature flags, sometimes called
feature toggles. Yeah.
Exactly. They're, well, they're a really
elegant fix, actually. Put simply, they're just boolean
variables like a simple true or false, and their whole job in
this continuous deployment world is to stop unfinished code from
actually running. So the codes gets committed and
it keeps happening, but the feature itself is basically
switched off sleeping. OK, so that explains the why
saving us from that merge hell. But how does this tiny little
switch actually work? How does it hold back what could
be like thousands of lines of new code in a huge system?
It's surprisingly straightforward.
While the developer is working on the feature, the flag, let's
stick with feature X is set to false everywhere.
And then wherever that new unfinished code lives, it gets
wrapped in a little check like an if statement.
Think of it like a protective active bubble.
OK, so the code effectively says if feature X is true, run this
new stuff, otherwise just skip it.
Carry on like normal with the old stable code path.
So even though the new code is technically on the servers
deployed everywhere, it doesn't execute for any real users,
right? And the sources give a really
good example to picture this. Imagine you're redoing a whole
web page. You definitely don't want users
seeing, you know, half built elements or weird errors.
No, definitely not. So you'd guard the whole page
rendering. You keep the old page code, you
write the new page code, and then you put the new version
inside a flag check, maybe called new page.
If new page is true, boom, they see the shiny new version.
If it's false, the system just shows the old reliable page
instead, Like flipping a switch. Exactly.
It's an instant toggle. But what's interesting is the
trade off this creates, at least for a while.
You end up with code duplication for some period.
Both the old page and the new page logic are sitting there in
the code base together. Duplication.
That sounds a bit messy, like technical debt.
Even if it's temporary. Is there a rule for how long
that's OK? The keyword is definitely
temporary. The idea is, once that new
feature is totally done, tested, rolled out, and critically, once
you're sure that old code isn't needed at all, then you clean it
up. You remove the old code and the
feature flag itself. It's often called flag hygiene
and yeah, it's a really important step people sometimes
forget. Gotcha.
So the beauty is decoupling those two things.
Merging code which happens constantly, and activating code
for users, which is the actual release.
They're not tied together anywhere.
Exactly total separation. OK, but then the sources say
companies often keep these flags around even after the features
out and working. They don't remove them
immediately, they use them for other things strategically.
You got it. That's where the flag evolves
from just being a safety net into a really powerful business
lever. And the first big strategic use
is something called a Canary release.
Ah, the Canary. Like testing the waters, right?
So the features deployed hidden behind its flag, but instead of
turning it on for everyone, you switch it on for just a tiny
fraction of users first, like maybe 5%.
Exactly. It's all about minimizing risk.
If something goes badly wrong, a major bug performance tanks.
You've only affected that small 5% group.
You get the warning signs immediately, you flip the flag
back off for them and the damage is contained.
Most users never saw a thing. And the name Canary, that comes
from the old coal mining practice, doesn't it?
Miners took a Canary down and if the air got bad, the bird would
collapse first, warning them to escape.
So the flag acts like that early warning, testing the safety on a
small scale before you go all in.
Perfect analogy. And once that initial 5% looks
good, the team managing the flags can slowly dial it up.
Maybe go to 10%, watch the metrics, then 25 percent, 50%
all the way to 100%. If any step shows problems, you
just dial it back by switching the flag off again.
For that group, it's controlled exposure.
Which seems like it flows naturally into the next big use
AB tests. How do flags help run those
experiments? But with AB testing, you
typically have two versions of something, version A and version
B. Both are probably stable and
ready. The feature flag in this case
isn't just on off, it's used to route different users to
different versions. It directs specific segments of
your users to see either A or B. OK, so the flying decides which
version a particular user sees, not if they see the feature at
all. You could send, say, half your
traffic to the old way, half to the new idea B, and then you
measure which one actually performs the better.
More clicks, more purchases, whatever.
Exactly right. And connecting this back, these
techniques Canaries in AB tests, they let companies move beyond
just guesswork decisions about whether to fully launch
something become data-driven. You see the real impact on
users, on revenue, on engagement before committing.
OK, that makes a lot of sense. But the logistics managing all
these switches, it must get complicated fast.
And that Canadian university study on the Chrome browser
really highlights the scale, doesn't it?
Absolutely. The numbers they found are kind
of staggering. They look at 39 Chrome releases
over five years from 2010 to 2015 and they identified over,
wait for it, 2400 separate distinct feature flags just in
the Chrome code base during that time. 2400 flags.
Wow. That's not just a few switches,
that's a massive control panel. And the growth is huge too,
right from a couple 100 initially to over 2400 by the
end. Yeah, huge growth.
But it wasn't just accumulating flags.
There's constant churn. The data showed that on average,
each new Chrome release added about 73 new flags, but it also
removed around 43 old ones as part of that cleanup, that flag
hygiene we mentioned. So there's this continuous
cycle. Add tests, maybe graduate, then
remove. That constant activity led to
the big net increase. We should probably linger on
that turn for a second, adding 73 flags per release.
That means constantly defining new guards, implementing new
code pads, and then having the discipline to clean up almost
half of them later. That sounds like a massive
maintenance effort. If you forget to remove one, it
just sits there dead code. That's exactly the risk, and
it's the core challenge of managing flags at scale.
Flag hygiene becomes critical when you're dealing with
hundreds or like Chrome, thousands of these things.
You can't just use the absolute simplest way of implementing
them and the. Simplest way is what just
defining it in the code itself? Yeah, just having like boolean
feature X equals false right there in the source code.
The problem is, if that flag is false and you need to change it
to true to start, say, a Canary release, you have to actually
edit the code file, commit the change, rebuild the entire
application and then redeploy everything.
Right, which kind of defeats the purpose.
If you have to do a full redeploy just to flip a switch,
you've lost that speed and separation the flag was supposed
to give you. You're back to waiting on
deployments. Precisely so.
For big systems with lots of flags, the solution is usually
external management. They use dedicated libraries or
systems basically like a big configuration database or table
that stores the current state true or false of every single
flag outside of the application code itself.
And the big win there is. Complete decoupling.
The running application code reads the flag state from this
external source at runtime. So the operations team or maybe
product managers can change a flag state, start an AB test,
rollback A problematic feature using a dashboard or an API
call. No code changes, no recompiling,
no redeploying. The change takes effect almost
instantly, Essential when you have 2400 switches to manage.
OK. So that makes sense for managing
the complexity. Now stepping back a bit, we
should probably clarify that feature flag is kind of a broad
term. The ones we've mostly talked
about for safe deployment, Canaries, AB test, those have a
specific right release flags. That's correct.
Release flags are all about managing the software delivery,
life cycle, risk reduction, gradual rollouts.
But there's another major category, one that's less about
technical risk and more about, well, the business model, and
those are called business flags. Business flags, How are they
different from release flags and practice?
They're used to essentially create different versions of the
software for different users, but all from the same deployed
code base. I think user permission,
subscription to yours, maybe regional differences.
The code for all features is deployed everywhere, but the
business flag controls who is actually allowed to use certain
features. OK, so that's how a company runs
like a free version and a paid version of their app from the
same underlying cut out. Exactly that, it's the classic
freemium model example. The code for the premium paid
features exists on the free users installation too, but
there's a business flag check. Maybe is premium user wrapped
around it? If you're not paying, that flag
is false and the feature is hidden or disabled.
If you upgrade, the flag flips to true and the feature
magically appears often without needing any new software
install. Wow.
OK, that's the Yeah, that's powerful.
It really makes you think. Feature flags aren't just a
deployment tactic anymore, they kind of transform the code
itself. It's not this fixed, monolithic
thing anymore. It becomes fluid, adaptable.
You can control not just if something runs, but who it runs
for based on business rules. It really is the technology that
underpins how modern software can be deployed continuously and
be flexible enough to meet complex business needs.
Well, that pretty much wraps up our deep dive into feature
flags. They really are this this clever
mechanism that lets developers move fast without, you know,
breaking things or driving everyone into that dreaded merge
hell. And importantly, keeping you,
the user, safe from seeing stuff that just isn't ready.
Yeah, they're fundamental now. So thank you for joining us for
this deep dive.