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

31–40 of 51 posts

Re: How to use feature flags without technical debt

#31

Post by kevan »

perlgeek wrote: post #20

On a tangent, how long-lived are feature toggles usually? I have very limited experience, and it points to a wide range from a few days to few months. When I stumble about a 1y+ old flag, I tend to delete it (and the dead code path that it comes with). What's your experience?

Our feature toggles have tended to live for months to years. Sometimes the really old ones were our fault for not removing, for example we rewrote our payments UI in mid-2014 and the flag stayed around for more than a year after we were at 100%.

Other times integration with third-party tools was what held us back. We rewrote our product pages in 2013 but our recommendations vendor was scraping the old version until 2015 because no one wanted to spend the vendor hours switching it to the new version.

My favorite was our add-to-cart actions. In the old platform we ended up with about 10 different user flows after clicking the "Add to cart" button from 2013-2016. This case was driven by heavy AB testing (should we show a confirmation modal? tooltip? send them to the cart page? what about an interstitial page that shows recommended add-on products? etc). In this case we accepted the overhead of lots of feature switches because a .1% conversion bump moved the needle pretty far.

The shorter flags have lived for a couple months as we build a new feature and then test into it at small percentages to work the bugs out. Once they're in at 100% and we're confident we rip the flag out.

Re: How to use feature flags without technical debt

#32

Post by retbull »

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.

Re: How to use feature flags without technical debt

#33

Post by startling »

kazinator wrote: post #28
perlgeek wrote: post #20

On a tangent, how long-lived are feature toggles usually? I have very limited experience, and it points to a wide range from a few days to few months. When I stumble about a 1y+ old flag, I tend to delete it (and the dead code path that it comes with). What's your experience?

Feature toggles can last decades. For instance GCC has a feature flag called -ansi which gives you C90 compatibility. C90 was superseded in 1999 by C99, and so that's 17 years of compatibility, and counting.

I don't think this is a feature flag in the same way the rest of the discussion is using the phrase.

Re: How to use feature flags without technical debt

#34

Post by lijason »

ori_b wrote: post #6
pkaeding wrote: post #3

Earlier quoted context omitted.

Author here. The point is not to delete the flag promptly, the point is to delete it cleanly , when you are confident the new feature is good.

In that case: I don't think I've ever seen any team have problems with how to delete a flag. The struggles tend to be about when.

When you say "when", do you mean depending when is the best time or making sure you, as a team, consistently do it? The latter is from my experience the hard part. It's hard to make sure that's part of the process as it's by necessity quite awhile after a feature has been released and no one is actively working on bugs related to it.

We've started to use automated scripts that identify "old" feature flags that are turned on to 100% that are still in the code base and treat them similar to bug tasks.

Re: How to use feature flags without technical debt

#36

Post by shoo »

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.

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.

Re: How to use feature flags without technical debt

#37

Post by alblue »

ori_b wrote: post #6
pkaeding wrote: post #3

Earlier quoted context omitted.

Author here. The point is not to delete the flag promptly, the point is to delete it cleanly , when you are confident the new feature is good.

In that case: I don't think I've ever seen any team have problems with how to delete a flag. The struggles tend to be about when.

Define a macro which has the feature name and a future date for when the build should start complaining. For extra points, have two dates: one for generating warnings and another for generating errors. Works like a charm.

Re: How to use feature flags without technical debt

#38

Post by mschuster91 »

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.

It's similar to the stuff you see in a raw "mysqldump" output, PHP extensions or in Microsoft's C stdlib headers. Shitloads of stuff hidden between #ifdef VER > xxx.

Pretty easy to deal with, tbh. And it's flexible as hell.

You can flame MS for a LOT of things, but not for ignoring backwards compatibility. You can take most age-old VC6 projects, import them in a modern VS version, and BUILD them and it will WORK.

Not so much in the Linux space. A statically compiled binary from Win95 may very well run on a Win7 machine (e.g. EarthSiege 2)... good luck trying to get a Linux binary from the same era running on a similarly fresh Linux kernel.

Re: How to use feature flags without technical debt

#39

Post by kazinator »

startling wrote: post #33
kazinator wrote: post #28

Earlier quoted context omitted.

Feature toggles can last decades. For instance GCC has a feature flag called -ansi which gives you C90 compatibility. C90 was superseded in 1999 by C99, and so that's 17 years of compatibility, and counting.

I don't think this is a feature flag in the same way the rest of the discussion is using the phrase.

How so? C99+ support/conformance is a compiler feature. That feature breaks/conflicts with some aspects of C90 support, an existing, older feature. So you need a feature flag. Inside comiler there are various places where you have the equivalent of "if C90 do this, else do that".

Re: How to use feature flags without technical debt

#40

Post by johansch »

aaron695 wrote: post #17
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...

Worked on many 10+ year code bases? Technical debt comes in many forms, like developers will refuse to work on messy code. Not sayimg you're wrong, could be survivor bias. Most code is thrown cause the messy project specs fail. Might be worth paying the extra for devs on the mess that works. But I don't like it, messy code is annoying hence why I'll remove technical debt. Which the company will pay for. Another cost…

> Worked on many 10+ year code bases?

Two separate codebases got 10+ year old while I managed the development on them, so, yeah. The latter one is something I started together with one colleague; it's now twelve years old and has 250 million monthly active users - Opera Mini; most of those users are in "growth regions". (I left after ten years of that.)

The main attitude I see nowadays in younger developers seems like an overreaction against technical debt... I blame HN etc. :)

Post reply on HN