---

The fourth link in my google search for ‘feature toggle’ is a link to this Building Real Software post. It’s about not about feature toggles described by Martin Folwer. It’s about feature toggles got wrong.

If you consider toggling features with flags and apply it literally, what you get is a lot of branching. That’s all. Some tests should be written twice to handle a positive and a negative scenario for the branch. The reason for this is a design not prepared to handle toggling properly. In the majority of cases, it’s a design which is not feature-based on its own.

The featured based design is created on the basis of closed components, which handle the given domain aspect. Some of them may be big like ‘basket’, some may be much smaller, like ‘notifications’ reacting to various changes and displaying needed information. The important thing is to design the features as closed components. Once you have it done this way, it’s easier to think about the page without notifications or ads. Again, disabling the feature is not a mere flag thrown in different pieces of code. It’s disabling or replacing the whole feature.

One of my favorite architecture styles, event driven architecture helps in a great manner to build this kind of toggles. It’s quite easy to simply… not handle the event at all. If you consider the notifications, if they are disabled, they simply do not react to various events like ‘order-processed’, etc. The separate story is to not create cycles of dependencies, but still, if you consider the reactive nature of connections between features, that’s a great enabler for introducing toggling with all of advantages one can derive from it with A/B tests, canary releases in mind.

I’m not a fan boy of feature toggling, I consider it as an important tool in architects arsenal though.

---

Comments

This is applicable only for the features completed and in that case it is better to release them instead of toggle them.

What about the feature is half way done and still more work to be done ?

by Muthu at 2016-11-29 08:44:05 +0000

This assumes your feature is a new or independant component.

What if the feature is a change to the serialization system or the file system? The code might not always be in a shape where adding a single conditional statement is possible.

by guibec at 2015-08-20 12:36:35 +0000

A feature isn't a change. A feature is a closed component. If you leak serialization over whole app, that's not a feature. If you have a separate component reponsible for this, than it is.

The foundations you mentioned are highly unlikely to be features. They won't be turned on and off. They will provide basics for the whole system.

Other parts of your app may be designed towards being a feature. That's all.

by scooletz at 2015-08-20 14:00:34 +0000

Hi Muthu,

Consider following case. You provide some kind of process manager that accepts one event and issues a few commands and its only one of three that will be introduced. In this case, if it's shippable you just ship it but you don't provide the input events, so that the processor cannot pick up its work.

by Szymon Kulec 'Scooletz' at 2016-11-29 20:45:13 +0000