05/12/2011

Trunk Based Development + Feature Flipping Vs Hybrid Mode (Trunk Based + Feature Branch)

Our team is using Hybrid model for source code management which is trunk based development + feature branch develpoment. It has been working quite well. And I have seen frictions moving towards trunk based development + feature flipping/toggling. With today's decision towards Kanban, trunk based development + feature flipping seems nature fit in the case for me. But most team members are not comfortable with that. And I do think team has made right decision.

In the meeting, team members have pointed out that

(1) If we don't experience now, why we need to move to new model
(2) The feature flipping would make code design less elegant
(3) What is adavantage of Feature Flipping

And team decides to continoue hybrid mode. And I believe in their decision. But there were still some doubts.

I have a better thought on it while I am on train. And the following summarize some of my thoughts.

If a team member don't experience any problem with current source code management methodology, I am strongly support decision to stay with current metdhology instead of moving. But if team expects large growth, I will suggest team to experiment some stories with feature flipping and be able to avoid difficulty of merging feature branches when team grows.

An elegant design is a fair point. It is not a time to think about feature flipping because the lost of software design doesn't provide any value with current infrastructure and testing frameworks that we have at the moment. But in the same time, I do think some design concept can be broken if it will bring more values such as performance driven scripts. But in the same time, the feature flipping can be base on very good OO design. But at the start, we don't need elegant design of feature flipping. A single configuration file and a general checking script should work.

Feature flipping's major advatanges:

(1) Minimize costs for merging branches in large teams environment
(2) Be able to hide features if features must be hidden because customer requirement or market decision

Disadvantages

(1) Codes will looks a little bit more messy
(2) Team must commit themselves to remove feature flags after a while
(3) Without clearning flags, your code base will be a big mess

4 comments:

harry huang said...

Are you guys using SVN or GIT?

We used to use SVN, and it doesn't trace the file/folder rename very well and brings too much trouble when merging, especially after a feature development and refactor the original code.

For GIT it looks much better, cheap branch, cheap merge, and the best thing is it trace all files rename and move.

Unknown said...

We are using SVN at the moment. To me, changing CVS is a big thing. But I will look into GIT for more detail and maybe a way to move from SVN to GIT.

Brad Appleton said...

My experience with feature toggles/switches is that it is often misused to create (and justify the maintenance of) super-smelly spaghetti-code convoluted by if-then-elsif-...-else code (or #ifdefs).

Doing feature toggling properly means that the feature toggling code is subject to the same rules for identifying code smells and refactoring them away, which eventually leads to higher-level patterns that make for a good, well-factored design that takes advantages of things likes replace-conditional-with-polymorphism, acceptance-tdd, mocks, dependency-injection, wrapper-facades, configurators, and other design patterns.

If all youre doing is adding lots of if-then-elsif-...-else code all over the place you are not only creating lots of technical/design debt (that far outweights the integration-debt you are trying to avoid) but you are systematically growing it and then leaving it in.

Unknown said...

Brad, thanks for the feedback. My thought is that we need to get dev team members to see benefits, starting with configuration file and move to a better design afterwards. Do you have suggestion on introducing feature toggling into a team without experience on that?