Snowing Code

Personal notes on software development


Pitfalls of feature toggles

(Publish date: 27/01/2016)

I read this great post on the shortcomings of feature toggles by Sebastien Lambla (as good as any other blog post by him, I should add; and it's great seeing him back to blogging in full throttle) and started writing a long comment since I had quite a few things to say about the subject, and then I decided there's enough content there for a blog post of my own, so here I am. Following Scott Hanselman's recommendation, I am attempting to own my own content.

So Seb talks at length about some of the technical aspects of introducing feature toggles everywhere in your code base, focusing on the problems of maintaining a code that is forwards compatible. In a talk I gave a couple of months ago about pitfalls of Continuous Delivery, I discussed the issue of feature toggles as well, but from more of a business angle. My recommendation for feature toggles, as with so many of the tools we have in our profession is first of all "Don't".

The first question you should start with is what are you trying to achieve with the feature toggle you were about to create. If it was a feature you or the business wished to test on your application to see whether or not the users need and to what extent is it worth spending the money on developing the feature, in most cases you could use an AB testing tool like optimize.ly or VWO to inject some javascript to add the feature or just some superficial empty interface components that do nowt, but track user interaction and could tell you how many users actually used it and what was the difference between your application running with or without the feature. If we take the example from Seb's post, if you wish to test a new feature of a block user button for you admins, you could start by just dropping a fake button that revokes/blocks users and display it only to administrators, then see if anyone actually tries to click the button. This could give you a good idea whether or not to implement the feature completely.

After you decided you really need this feature toggle as a way to test your application with this new awesome idea, stop for a second and take a look at how many other feature toggles you have already got running currently running and how many of them are running on the same area of the application. Introducing yet more and more feature toggle will end up messing with the way you track user interaction and you calculate the difference between the application having or not the feature under test. Other features under test might make your test less appealing to the users or you might see an increase in profit but wouldn't know to what feature you should attribute this increase. Keep the number of your current feature toggles to a minimum.

If you wish to employ a feature toggle to allow the development of a rather big feature that might take some time to finish, especially if you're continuously delivering new versions of your application, you need to be extremely careful. Feature toggles are the most efficient way to hide Work In Progress that takes time. Don't forget the definition of done is "the feature is on the live environment and being used by users". Simply put, while you're working on a feature toggle your team continuously deliver other features. Your hidden code finds its' way to the live environment too, however it is not being used by anyone, and is therefore not done yet. In the mean time, your work is in progress, not delivered and not providing any value added to the business. Waste. There might be a way to split even more the work load here and create even smaller chunks of work that could be delivered.

To summarise, remember you might be able to AB test your features by injecting some javascript and get the same information on the utility of the feature. Otherwise, you should not overdo your AB testing, as it may mess with the results of your tests. Finally, feature toggles are a possible waste, as the work you're doing may still not be used by the application users.

blog comments powered by Disqus