Live data from Hacker News

Feature Toggles

martinfowler.com

41–50 of 50 posts

Re: Feature Toggles

#41
A more powerful version of these things are called dynamic variables, and they're worth some study beyond feature selection and testing: Otherwise you just get global variables with funny names.

Many languages have some dynamic variables (this, self), and few languages have first-class support for them (notably CL, Perl). While dynamic variables are tricky to emulate fully, as long as you have the ability to catch exceptions and closures, a very fair simulation can be made:

    (function(){
      var o={};
      D=function(k){return o[k]}
      dlet=function(b,f){
        var r,s={};function oops(){for(var k in s)o[k]=s[k]};
        for(var k in b)s[k]=o[k],o[k]=b[k];
        try{r=f()}catch(e){oops();throw e;}; oops();return r;
      };
    })();
Besides feature variables that are globally accessible, one useful thing you can do with dynamic variables is set up error handlers. Consider the situation where you are saving a big file to the disk and run out of space. If you:

    save_stuff(); if(oops)throw 'out of space'; save_more_stuff();
then your slow saving operation needs to be retried from the start, however if you use a dynamic variable to look up the handler, you can:

    save_stuff(); if(oops)D('out of space')(next); else next();
    function next(){ save_more_stuff(); }
The user can then use their fancy multitasking environment to clean up some space, and we can continue our operation. I generally recommend this form of error handling anyway.

Another useful thing is for context: Imagine you have a user interface choice between an HTTP response and a command line interface. One way to do this is to have two applications, and another way is DI (dependancy injection: pass the "response" object around), however another way is using dynamic variables:

    D("output")(...);
This has the benefit of not requiring an extra argument to all of your functions.

This happens more than you might think: Many people when confronted with all their dynamic variables put them into some kind of "master object" (current logged in user, output handler, database settings, etc), however dynamic variables

When you do this, a lot of features become very easy to set:

• Capturing output (simply mock a new "output" var)

• Testing logic: dlet({db:test_settings},r)===dlet({db:live_settings},r)

• Impersonate users (if the right credentials are available)

And so on.

Re: Feature Toggles

#42

Earlier quoted context omitted.

I think the calculus changes when you consider teams with 1000s of programmers committing 100s of changes per day. Keeping feature branches up-to-date can pretty quickly adds up to a lot of time and creates a lot of friction for refactoring/cleanup-type changes. Feature toggles enable some additional cool stuff like partial/incremental rollout and A/B testing, which really pay dividends.

I've never worked on codebases with so many programmers, but I kind of feel that's if that's how you work, 'you're doing it wrong'. Why would you have so many programmers working on a single codebase, why not split it up in distinct parts? If that's not possible because so much stuff is shared, how can you possibly work effectively with so many people changing so many things?

1000 programmers on a single codebase means:

• "master" always builds

• "master" is always stable

Any testing has to be done with in-code branches, and has to be built in-place incrementally so that other developers can see you touching stuff (and can be defensive about their tasks).

Re: Feature Toggles

#43
post #35

Earlier quoted context omitted.

I'm not quite sure I understand all of your comment, but I can respond to why one might want feature toggles rather than branches. One of the activities that can really improve the quality of code on a team is continuous integration. Now, I don't mean setting up a "CI" server to run tests for you when you push your code. I mean actually merging your code with your fellow programmers every 20 minutes or so. The reason…

You can never break any code. That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems. It's far better to have a safe environment where a dev can branch a new feature, break the whole codebase complet…

> That's a ludicrous expectation will lead to developers being scared of merging changings, which will in turn lead to them hiding mistakes, refusing to talk through their code, and ultimately hacking things in to the codebase that "work" but are terrible solutions to problems.

Maybe, but it can just as easily lead to good practice. E.g. if you're scared to change a particular piece of code, that's a red flag that that particular piece of code is inadequately tested - and "am I scared?" is a much better metric than automated test coverage reports.

Re: Feature Toggles

#44
Feature toggles are useful but should be used with great care, especially in complex codebases. There are challenges to using them. If you aren't careful or don't have very good test coverage you can break unknown sections of code.

The other pain is removing them, again if not done carefully or with very good test coverage you can unknowingly break things.

Re: Feature Toggles

#45

An interesting way to implement feature toggles is with your existing A/B test system. Basically, create an "experiment" for each new feature. Set the initial "treatment" size to something like 10%. Once the feature has been validated in production, set the treatment size to 100%.

It's scary that you have to explain this. This is A/B testing 102, all new features are experiments.

Re: Feature Toggles

#46
post #13

Architecture people tend to speak in trivial examples. Swapping out an algorithm with a backwards compatible one? Good for you! It doesn't matter how you do it because it's the most trivial example one could think of. (A more realistic example would be new functionality that touches large parts of the code base, or compliance with a new API that the payment processor switches that has more data on every payment as it…

I'm not quite sure I understand all of your comment, but I can respond to why one might want feature toggles rather than branches. One of the activities that can really improve the quality of code on a team is continuous integration. Now, I don't mean setting up a "CI" server to run tests for you when you push your code. I mean actually merging your code with your fellow programmers every 20 minutes or so. The reason…

Most CI build tools can test branches. They can even merge from upstream on a temporary branch, return the failing tests, tell you when they started failing or being flaky (was it on a commit introduced to master by a recent merge?), then you know for every commit whether it would be green when you merge to master.

Re: Feature Toggles

#47

Earlier quoted context omitted.

We recently feature toggled exactly your use case - switching to a new API from our payment provider which needs more information. You seem to be working on the assumption that everything has to be toggled or nothing. What we did was to collect the additional information for everyone (its a low risk change after all), and then slowly roll out the new payment API, starting with staff, then friends & family, and finall…

Has anyone tried Launchdarkly for this?

While it looks pretty slick, I wouldn't personally pay a monthly fee for feature flagging. Our (pretty basic) implementation is just over 50 lines of code, and allows us to do all the targeting we need - either individual users, or particular groups of users we've tagged as having the feature. It just doesn't seem worth shelling out extra for that.

Re: Feature Toggles

#48
This all thing reminds me why I love so much so called Enterprise Developers and Martin Fowler with Thoughtworks and their articles (no offense, thanks to Martin for the idea of refactoring, but such things are wrong). Seriously, they take simple idea reducible to more general principles which is not a very big deal and start build ad-hoc ideology and terminology around it: Hm-m, some abstraction around feature flags config? I think we should call it "toggle router". Then people start to create frameworks (not libraries) for this and after all technical recruiters will end-up searching for people with particular "toggle router experience".

Re: Feature Toggles

#49

It's interesting to see this here now, because ~10 hours ago, when it came up in my feedly stream, I tried to submit it and only got the message that it's already submitted. I searched here for it but could not find it, though.

Thanks for the downvotes for being curious how Hacker News works. :(

Re: Feature Toggles

#50
I am pretty disapointed by the limited use cases pictured in the article. I pinged the author without success.

Check at bottom of ff4.org page 10 others.

E.g : Deliver your product with toggles off on each node of your cluster and when all are ready : toggle on - no more inconsistency during release - no rollback as you simply toggle off if not working.....

Post reply on HN