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

31–40 of 50 posts

Re: Feature Toggles

#31

Post by LoSboccacc »

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 never understood why some people are scared of branching.

we are using a similar pattern to add advanced features to certain plan tiers, can't do that with branching on saas deployments - the project isn't complex at all.

we also use it to do progressive release, so that a feature get tested on, say, 10% of the userbase and we improve on their feedback before releasing it at large, but that's secondary to our use case

Re: Feature Toggles

#32

Post by misterkwon »

jon-wood wrote: post #29
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 finall…

Has anyone tried Launchdarkly for this?

Re: Feature Toggles

#33

Post by gioele »

I find the `scientist` gem by GitHub [1] a very nice way to approach the problem of testing alternative implementations.

Basically `scientist` always runs both the original code and the new code.

  def allows?(user)
    science "widget-permissions" do |e|
      e.use { model.check_user(user).valid? } # old way
      e.try { user.can?(:read, model) } # new way
    end # returns the control value
  end
It returns the result given by the original code, but it also compares both results and store statistics about when the two codes produce different results. This allows you to run experiments directly in the deployed branch without any service disruption.

[1] https://github.com/github/scientist

Re: Feature Toggles

#34

Post by junto »

justinucd wrote: post #30
junto wrote: post #16

Earlier quoted context omitted.

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?

Currently we are forced to ignore it until it becomes a performance problem or a new feature touches the same code. This is simply because new features are paid for by clients and they take priority over technical debt.

We only tend to refactor code (as a rule) when you are already working inside that code section on something new (feature, improvement or bug).

Otherwise junior developers have a tendency to want to refactor all the things!

If you wrote a new unit test, or altered an existing one to accommodate new code, then knock yourself out and refactor away and knock yourself out!

Re: Feature Toggles

#35

Post by onion2k »

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…

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 completely if necessary, and only merge things back in when they're confident that their solution is a good one (with a review of the pull request by a maintainer or two).

The aim of writing software is to make a good product that solves a problem. It is not to 'never break the build' or 'merge as often as possible'.

Re: Feature Toggles

#36

Post by einrealist »

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…

Branching adds too much "meta complexity". That is complexity that you cannot track in actual deployed code. You need processes to manage the branches and to determine when and how to merge. And merging branches is always an error prone process itself. And if you have one deployment target, like a web application, you probably need several staging environments for your branches, so branching does not become the bottleneck towards production. Also if you have test code that is maintained elsewhere (e.g. UI tests), that code cannot reflect your feature changes transparently.

In comparison to that: feature toggles. You need one branch (developers can still can have private branches). And the transitions are transparent in your code. Actually, all the complexity is forwarded to the code and toggle management. Most people understand the concept of toggles better than branching workflows / processes. Toggles are easier to test and your tests do reflect that features are changing.

I made my decision. I will never have official branches again in any of the projects I supervise.

Re: Feature Toggles

#37

Post by UK-AL »

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…

Well your merging a lot earlier which means less conflicts. Other benefits include, being able to release to a select group of people, and being turn off features easily if something goes wrong

Re: Feature Toggles

#38

Post by geocar »

kbenson wrote: post #25
mikekchar wrote: post #19

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…

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…

No, that's not the point of the branch.

The point of a branch is to label concurrent development.

There's nothing about a branch that says it must be "test code" or "pre-release" code, but your perspective is common: Everyone wants blue/green or to fully distinguish between "live code" and "test code" because they think the problem isn't theirs to solve: That their manager doesn't give them enough time, or their predecessor didn't like clean code like you do, or that's just what test databases are for.

Infrastructure that really supports branching is uncommon because it's difficult and it requires very careful consideration with regards to the entire architecture. Some examples of systems that actually use branching correctly:

* Implement random 0.5%, 1%, 5% etc traffic diverted to test branches * Front-end web service selects branch from URL or cookie * Backend service compares 5% live queries against test database and compares results

If your system doesn't have something like this, you're really missing out: Really big applications (the kind that span multiple continents) don't have an "atomic operation" to their deploy, and you shouldn't try to pretend that they do. That's how we got IPv6.

Re: Feature Toggles

#39

Post by eps »

Oi vey.

Coming from the good old C I am frankly baffled how some triviality like this one can be wrapped into so many fancy words and a full article. This is like hearing that taking your shoes off when entering home is a good idea. Do you know why? Let's start with an example. Picture this - it's raining outside, water soaks the earth and some of it may get on the soles of your shoes... you get the idea. It's a subject hardly worth a passing mention if any. "Feature toggles". Bah. Makes you wonder what will happen when they discover function pointers or, god forbid, the config files. Now that will likely be worthy of at least a book.

Re: Feature Toggles

#40

Post by lucaspiller »

samwgoldman wrote: post #15
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 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?

Post reply on HN