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

Feature Toggles

martinfowler.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Feature Toggles

#21

Post by Twisell »

xorcist wrote: 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…

Actually I would not necessarily oppose toggling and branching. These two method remains tools that can be used separately or together to achieve some goal.

I don't see why one shall not use branching to implement a toggling API.

Re: Feature Toggles

#23

Post by prostoalex »

egometry wrote: post #3

At IMVU we had feature toggles rolled into the A/B Experiment system. It proved to be a vital part of Continuous Deployment. Basically: Wrap every new feature in an Experiment Toggle. Deploy to production (once ready for 'non sandbox' testing). Turn on for test users, test. If good, start the rollout to experimental users. If after weeks the numbers worked out, turn it on for everyone... ...but if at any point unexpe…

Same at Facebook https://www.quora.com/How-does-Facebooks-Gatekeeper-service-... with rollout UI similar to what advertisers see on ad purchasing UI (by country, college, demographics, etc.)

Re: Feature Toggles

#24

Post by jammycakes »

One point to be aware of with feature toggles: if you're using them as a substitute for branching and merging in your VCS, you're deploying code into production that you know for a fact to be buggy, insufficiently tested, and incorrect. If your feature toggles themselves have bugs, or don't properly isolate your new code, you could easily run into problems up to and including data corruption. You may be switching your controllers on and off, but are you also toggling your static assets such as HTML, CSS and JavaScript?

People are often scared of feature branches because of large, tricky merge conflicts. However, large, tricky merge conflicts warn you (noisily) of problems such as these before your code gets into production. Problems with feature toggles, on the other hand, don't show up until after your code gets into production, by which time it may well be too late.

Re: Feature Toggles

#25

Post by kbenson »

mikekchar wrote: post #19
xorcist wrote: 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…

But that's the point of a branch, a place to put your code before it's integrated into the whole as an "atomic operation" so:

You aren't possibly breaking live code

You making lots of changes to code other people might be changing, causing conflicts

You don't need to either go back and remove the old branches after the deployment or leave them in to clutter the code.

You don't have to worry as much about overlooking some portion of the codebase using the old code (if you change the API enough to make it incompatible), since you can literally remove old APIs and cause compile errors or easily detectable runtime errors.

You can change data structures with conversion scripts where it's not feasible to overlap functionality (whether those be code constructs, or disk/DB format).

Re: Feature Toggles

#28

Post by alkonaut »

xorcist wrote: 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…

> Architecture people tend to speak in trivial examples.

Even just having a single deployment (such as a web app) is a huge simplification of "deployment" compared to other software such as a driver, firmware, desktop application or just about any other piece of software.

Re: Feature Toggles

#29

Post by jon-wood »

xorcist wrote: 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…

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 finally doing a phased rollout to customers.

Feature toggling not only allowed us to roll it out, but also to rapidly roll it back to deal with issues, and resulted in a very smooth implementation of a feature that had potential to directly affect revenue.

Re: Feature Toggles

#30

Post by justinucd »

junto wrote: post #16
jbardnz wrote: post #4

I really like the idea of feature toggles but i'm scared of quickly having a lot of technical debt because of them. I was looking at using something like https://launchdarkly.com but the pricing is very expensive even at fairly small scale.

We use feature toggled a fair amount on our SAAS application. It does create technical debt which at some point has to be addressed. One thing that confuses our junior developers is the difference between a feature toggles and a client permission. Often they misuse a feature toggle as a client permission, simply because only one client is using that feature (currently).

How do you typically address or mitigate your technical debt?
Post reply on HN