Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to use feature flags without technical debt

blog.launchdarkly.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: How to use feature flags without technical debt

#41

Post by 0x0 »

Sounds dangerous. Later commits on master might actually add more if(feature-flag) statements, so if you then just mindlessly merge the cleanup branch, you'll miss the added ifs.

I'd prefer to create a cleanup branch like any other feature branch only when actually going to clean up, and spend the extra cost getting back in context, studying all the if(feature-flags) from master. Otherwise you might miss some, or you might forget some interaction that you learned after feature deploy.

Re: How to use feature flags without technical debt

#42

Post by kazinator »

retbull wrote: post #32
kazinator wrote: post #24

In the TXR language interpreter, I have a -C option which takes a numeric argument: it means, simulate the old behaviors of version N. If you don't specify -C, you get the latest behavior. Throughout the code, old behaviors are emulated, subject to tests which look similar to this: if (opt_compat && opt_compat I think that tying specific old behavior to a proliferation of specific options is a bad idea. It does provi…

Is there any way you could explain that again? I don't quite get what you are doing.

Without knowing which part you don't get, there is a risk I just repeat everything in a scrambled order!

The highlights are:

We have software (a programming language and its library) that is versioned in a simple, linear way: it goes from version N, to N+1, to N+2 and so on.

Users who are using version K now depend on some features. Suppose the behavior in version K+1 changes some of the features. The users will be rightfully unhappy; they upgrade to K+1 and things work differently, breaking their code.

To anticipate this, we can have a command line switch or environment variable whereby users can request "please emulate version K". Then version K+1 (and K+2, K+3 ...) will restore those behaviors which were altered starting in K+1.

This does not disable purely new features that don't break existing behaviors. For instance, if a two-argument function can now take an optional third argument, such that a two-argument call behaves exactly the same way as before, that won't be subject to emulation. A whole new function that didn't exist in version K is not going to disappear under K emulation.

This isn't a perfect strategy. Things can go wrong. But it's fairly decent.

Re: How to use feature flags without technical debt

#43

Post by kazinator »

shoo wrote: post #36
retbull wrote: post #32

Earlier quoted context omitted.

Is there any way you could explain that again? I don't quite get what you are doing.

the user can optionally specify which version of behaviour they want. This is named the `opt_compat` value in the code. All through the code there are checks against the `opt_compat` value to decide which version of which old/current behaviour to use.

And the opt_compat has C integer/boolean semantics in this case, so the test

  if (opt_compat) ...
tests whether the option has a nonzero value (has been specified).

And so

  if (opt_compat && opt_compat
means "user has requested compatibility, with a value of 130 or less".

By the way -C 0, which would look as a Booealn false, as if -C were not specified, is not allowed. If the user specifies -C N such that N is lower than the oldest version that we emulate, the implementation terminates with an error message like "sorry, compatibility with versions less than 70 is not supported by version 140".

Re: How to use feature flags without technical debt

#44

Post by pkaeding »

0x0 wrote: post #41

Sounds dangerous. Later commits on master might actually add more if(feature-flag) statements, so if you then just mindlessly merge the cleanup branch, you'll miss the added ifs. I'd prefer to create a cleanup branch like any other feature branch only when actually going to clean up, and spend the extra cost getting back in context, studying all the if(feature-flags) from master. Otherwise you might miss some, or you…

Yeah, I think if you mindlessly do anything, you're gonna have a bad time.

Think of the cleanup branch as a running list of changes that you know you will need to make to remove the flag. Any future references to the flag should keep this cleanup list in mind. Code reviewers should keep these cleanup lists in mind.

This list of cleanup tasks happens to be expressed as a branch in your VCS (this is a pretty good way to express changes that need to be applied to a codebase). You will still need to be careful when you execute that list, but it will be helpful to have the running tally of things that need to be done.

Re: How to use feature flags without technical debt

#45

Post by vemv »

pkaeding wrote: post #21
vemv wrote: post #13

Haven't tried it myself, but why not use authorization libraries instead of specialized 'toggle' libraries? After all, both are concered with whether user X is allowed to do Y. Using just one approach might be a clean, maintainable approach. The original code `if can?(:use_feature_x, user)` is written just once, and then never needed to be removed. The only thing that changes, gradually and cleanly, are the business…

In canary launches, you might want to roll a new feature out to 10% of your users, then 20%, etc. Once it is released to 100% of your users, you might want to remove the check, since it is a no-op. I'm not aware of any authorization libraries that let you grant access to a percentage of your users, but maybe they are out there? It is a strange use case from an 'authorization' standpoint.

no-op point is true (except for logged out users - then the check is still useful)

Anyway, how do you consistently decide to which 10% you show the new feature?

That piece of data is better stores in your Users table, as I see it. Plays well with authorization libs.

Re: How to use feature flags without technical debt

#46

Post by pkaeding »

vemv wrote: post #45
pkaeding wrote: post #21

Earlier quoted context omitted.

In canary launches, you might want to roll a new feature out to 10% of your users, then 20%, etc. Once it is released to 100% of your users, you might want to remove the check, since it is a no-op. I'm not aware of any authorization libraries that let you grant access to a percentage of your users, but maybe they are out there? It is a strange use case from an 'authorization' standpoint.

no-op point is true (except for logged out users - then the check is still useful) Anyway, how do you consistently decide to which 10% you show the new feature? That piece of data is better stores in your Users table, as I see it. Plays well with authorization libs.

The way LaunchDarkly does it is to hash the user key, along with the feature key. This way the same users aren't always included in the '10% set' for all features, but they are consistently in the 10% set for a single feature.

This also allows the decision to be made in memory, without an additional round-trip to the DB.

Re: How to use feature flags without technical debt

#47

Post by johansch »

dahart wrote: post #27
johansch wrote: post #9

This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...

Debt, both technical and financial, is always best avoided. And in both cases, once you have it, you have to pay it down sooner or later, and the later you do the more expensive it gets. It is a tool, but having it is always a negative that is offsetting a bigger negative. By all means, take the loan when you need a boost that you can't otherwise afford. But take the smallest loan you need, and pay it back as fast as…

Do you think of VC the same way?

Re: How to use feature flags without technical debt

#48

Post by adamconroy »

backslash_16 wrote: post #29
jupp0r wrote: post #8

If you do feature flags by inserting if blocks throughout your code you will create tech debt anyways. The goal is to have one if block and hide the changed behavior behind interfaces (or polymorphic functions if you are using functional languages). Dependency injection is your friend. If you don't do this, you won't scale beyond a hand full of feature flags. Chrome has hundreds, for example.

Can you expand on this? I'm interested to see how this works in a real code base. I'm thinking something like an initial (maybe massive) if block in the setup of the application that sets all of the behavior/features by declaring which implementations get set to which interfaces? After this if block, all of the DI stuff is set? This of course means you need to use a DI framework of some sort. Using feature flags is s…

I was about to say the same thing as your parent. I recently had a nice feature toggle experience using a strategy pattern with DI.

Basically there was one 'if' statement in the DI container configuration code that looked up a config. Basically

if (newPricingStrategy) bind IPricingStrategy to NewPricingStrategyImplementation else bind IPricingStrategy to OldPricingStrategyImplementation

Re: How to use feature flags without technical debt

#49

Post by adamconroy »

johansch wrote: post #9

This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...

i agree and on top of that I've always thought 'technical debt' was a bad analogy (like most analogies).

my reasoning is that real world debt is inescapable, whereas if someone writes some crap code, which is hard to read/maintain/extend, then the debt is only called in if someone has to maintain it. My intuition is that a fair percentage of code that once it works and is tested, never has changes made, or the whole system is replaced without the code ever changing.

if you buy a house with a mortgage, but never live in it, you still have to pay the debt. if you write some code and don't ever touch it again, there is no debt to pay.

Re: How to use feature flags without technical debt

#50

Post by adamconroy »

dahart wrote: post #27
johansch wrote: post #9

This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...

Debt, both technical and financial, is always best avoided. And in both cases, once you have it, you have to pay it down sooner or later, and the later you do the more expensive it gets. It is a tool, but having it is always a negative that is offsetting a bigger negative. By all means, take the loan when you need a boost that you can't otherwise afford. But take the smallest loan you need, and pay it back as fast as…

no, often you don't have to pay for technical debt. the code may never be refactored, and / or the whole system / module replaced before lots of code is touched.
Post reply on HN