Feature development and branching
4 views
Skip to first unread message
Matthew Fernandez
Feb 11, 2015, 2:40:36 AM2/11/15
to code-p...@googlegroups.com
Hi all,
It's been a while since anyone's posted in this group, but I watched a
video recently that sparked some questions I wanted to ask others
about. Someone at work sent around this video about engineering
practices at Spotify: https://www.youtube.com/watch?v=Mpsn3WaI_4k.
Most of it's pretty unsurprising, but the one thing that caught me off
guard was that they actually ship unfinished features, but disable
them. The implication seemed to be that they do all development on a
single branch and just conditionally disable a feature until it's
ready.
I've never worked in a group that ran this way, and I thought more or
less everyone had now converged on the model of feature branches that
are merged back into your master/trunk when they're ready. Do any of
you work in a team where all development happens on a single branch
and, if so, does it actually work productively?
Cheers,
Matt
It's been a while since anyone's posted in this group, but I watched a
video recently that sparked some questions I wanted to ask others
about. Someone at work sent around this video about engineering
practices at Spotify: https://www.youtube.com/watch?v=Mpsn3WaI_4k.
Most of it's pretty unsurprising, but the one thing that caught me off
guard was that they actually ship unfinished features, but disable
them. The implication seemed to be that they do all development on a
single branch and just conditionally disable a feature until it's
ready.
I've never worked in a group that ran this way, and I thought more or
less everyone had now converged on the model of feature branches that
are merged back into your master/trunk when they're ready. Do any of
you work in a team where all development happens on a single branch
and, if so, does it actually work productively?
Cheers,
Matt
Tom Allen
Feb 11, 2015, 3:13:07 AM2/11/15
to code-p...@googlegroups.com
I haven't watched the video, but from your words I interpreted this as a fairly well-known pattern of introducing "dark code". That is, code that is in place, but isn't called because a feature flag is not yet set. When the code is mature, you toggle this flag and "release" the feature.
In my limited experience, this is more useful in web-development circles where you can selectively change feature flags for a subset of your users, and thus more easily perform A/B testing of new ideas.
Personally, I dislike working without feature branches and git-style merging, but am involved in a work project still using SVN where us two developers generally work in the one master branch unless there's an obviously long-lived feature that will affect the other developer's process. Then again, we're in an embedded environment and our releases are only about once every three months anyway.
Cheers,
Tom
--
You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to code-pro-bon...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Venus Zhang
Feb 11, 2015, 3:43:22 AM2/11/15
to code-p...@googlegroups.com
We basically do that in our company here and rarely have feature branches. Reason being that only certain customers paid and ask for this feature and things are basically hidden from UI until it is ready. This approach is working ok but we would occasionally have features that causes bugs in the existing functionality. Other than that, it works for us ok.
Sent from my iPhone
Sent from my iPhone
Patrick Coleman
Feb 11, 2015, 7:45:52 AM2/11/15
to code-p...@googlegroups.com
Thanks for the video!
I agreed with Tom in regards to "dark code" -
For web apps, the a/b testing is vital, but also you can get even trickier by late-loading feature code only when it is turned on, so having the code submitted doesn't impact the initial download size that much. For native mobile apps it's a bit trickier (it will bloat your binary).
I haven't tried feature branches myself, but it feels like there are enough people submitting to the codebase I work on that, for large changes, you'd likely have issues with others not breaking stuff you rely on in the meantime - and this just gets worse the larger the feature is, so the only way to get code that will survive other changes is to submit to the main branch.
Matthew Fernandez
Feb 11, 2015, 8:28:40 PM2/11/15
to code-p...@googlegroups.com
Interesting to hear that this is actually much more common than I suspected.
On 11/02/15 19:12, Tom Allen wrote:
> In my limited experience, this is more useful in web-development circles where you can
> selectively change feature flags for a subset of your users, and thus more easily perform A/B
> testing of new ideas.
Yes, A/B testing is one of their claimed motivations. I was just surprised that they still ship the
disabled code to the control group. Maybe my surprise is just because this is not what you would do
in kernel development. You generally drop dead code at compile time in order to reduce your attack
surface. Disabled code in your kernel bloats memory usage and introduces potentially useful ROP
gadgets for attackers. I concede that neither of these reasons are valid motivations in web
development though.
On 11/02/15 19:12, Tom Allen wrote:
> Personally, I dislike working without feature branches and git-style merging, but am involved in
> a work project still using SVN where us two developers generally work in the one master branch
> unless there's an obviously long-lived feature that will affect the other developer's process.
Yeah, feature branches are a bit difficult to manage under SVN. I tend to use private branches to
hide my chaotic work flow from others until I'm ready to condense everything into a coherent
patch(es). Then again, I suppose there's nothing to prevent you doing this on a smaller scale and
still regularly committing logical patches to master.
On 11 February 2015 at 09:43, Venus Zhang wrote:
> We basically do that in our company here and rarely have feature branches. Reason being that
> only certain customers paid and ask for this feature and things are basically hidden from UI
> until it is ready. This approach is working ok but we would occasionally have features that
> causes bugs in the existing functionality. Other than that, it works for us ok.
This is actually one of the things Spotify points out as an advantage, namely that integration
problems hit you earlier rather than later.
On 11/02/15 23:45, Patrick Coleman wrote:
> I haven't tried feature branches myself, but it feels like there are enough people submitting to
> the codebase I work on that, for large changes, you'd likely have issues with others not breaking
> stuff you rely on in the meantime - and this just gets worse the larger the feature is, so the
> only way to get code that will survive other changes is to submit to the main branch.
It seems to me it depends how interconnected new features are or, relatedly, how much of the same
code they're touching. We try to keep ongoing development efforts as orthogonal as possible, but if
two features need to touch the same code we generally do both together in a branch. Of course there
aren't really any hard and fast guidelines at NICTA, so anyone's welcome to work in their own branch
and cop the pain of rebasing master regularly.
On 11/02/15 23:45, Patrick Coleman wrote:
> Thanks for the video!
> I agreed with Tom in regards to "dark code" -
>
> For web apps, the a/b testing is vital, but also you can get even trickier by late-loading feature
> code only when it is turned on, so having the code submitted doesn't impact the initial download
> size that much. For native mobile apps it's a bit trickier (it will bloat your binary).
>
> I haven't tried feature branches myself, but it feels like there are enough people submitting to the
> codebase I work on that, for large changes, you'd likely have issues with others not breaking stuff
> you rely on in the meantime - and this just gets worse the larger the feature is, so the only way to
> get code that will survive other changes is to submit to the main branch.
>
>
>
> On 11 February 2015 at 09:43, Venus Zhang <venus...@hotmail.com <mailto:venus...@hotmail.com>>
On 11/02/15 19:12, Tom Allen wrote:
> In my limited experience, this is more useful in web-development circles where you can
> selectively change feature flags for a subset of your users, and thus more easily perform A/B
> testing of new ideas.
disabled code to the control group. Maybe my surprise is just because this is not what you would do
in kernel development. You generally drop dead code at compile time in order to reduce your attack
surface. Disabled code in your kernel bloats memory usage and introduces potentially useful ROP
gadgets for attackers. I concede that neither of these reasons are valid motivations in web
development though.
On 11/02/15 19:12, Tom Allen wrote:
> Personally, I dislike working without feature branches and git-style merging, but am involved in
> a work project still using SVN where us two developers generally work in the one master branch
> unless there's an obviously long-lived feature that will affect the other developer's process.
hide my chaotic work flow from others until I'm ready to condense everything into a coherent
patch(es). Then again, I suppose there's nothing to prevent you doing this on a smaller scale and
still regularly committing logical patches to master.
On 11 February 2015 at 09:43, Venus Zhang wrote:
> We basically do that in our company here and rarely have feature branches. Reason being that
> only certain customers paid and ask for this feature and things are basically hidden from UI
> until it is ready. This approach is working ok but we would occasionally have features that
> causes bugs in the existing functionality. Other than that, it works for us ok.
problems hit you earlier rather than later.
On 11/02/15 23:45, Patrick Coleman wrote:
> I haven't tried feature branches myself, but it feels like there are enough people submitting to
> the codebase I work on that, for large changes, you'd likely have issues with others not breaking
> stuff you rely on in the meantime - and this just gets worse the larger the feature is, so the
> only way to get code that will survive other changes is to submit to the main branch.
code they're touching. We try to keep ongoing development efforts as orthogonal as possible, but if
two features need to touch the same code we generally do both together in a branch. Of course there
aren't really any hard and fast guidelines at NICTA, so anyone's welcome to work in their own branch
and cop the pain of rebasing master regularly.
On 11/02/15 23:45, Patrick Coleman wrote:
> Thanks for the video!
> I agreed with Tom in regards to "dark code" -
>
> For web apps, the a/b testing is vital, but also you can get even trickier by late-loading feature
> code only when it is turned on, so having the code submitted doesn't impact the initial download
> size that much. For native mobile apps it's a bit trickier (it will bloat your binary).
>
> I haven't tried feature branches myself, but it feels like there are enough people submitting to the
> codebase I work on that, for large changes, you'd likely have issues with others not breaking stuff
> you rely on in the meantime - and this just gets worse the larger the feature is, so the only way to
> get code that will survive other changes is to submit to the main branch.
>
>
>
> wrote:
>
> We basically do that in our company here and rarely have feature branches. Reason being that
> only certain customers paid and ask for this feature and things are basically hidden from UI
> until it is ready. This approach is working ok but we would occasionally have features that
> causes bugs in the existing functionality. Other than that, it works for us ok.
>
> Sent from my iPhone
>
> > On 11 Feb 2015, at 6:40 pm, Matthew Fernandez <matthew....@gmail.com
>
> We basically do that in our company here and rarely have feature branches. Reason being that
> only certain customers paid and ask for this feature and things are basically hidden from UI
> until it is ready. This approach is working ok but we would occasionally have features that
> causes bugs in the existing functionality. Other than that, it works for us ok.
>
> Sent from my iPhone
>
> > On 11 Feb 2015, at 6:40 pm, Matthew Fernandez <matthew....@gmail.com
> <mailto:matthew....@gmail.com>> wrote:
> >
> > Hi all,
> >
> > It's been a while since anyone's posted in this group, but I watched a
> > video recently that sparked some questions I wanted to ask others
> > about. Someone at work sent around this video about engineering
> > practices at Spotify: https://www.youtube.com/watch?v=Mpsn3WaI_4k.
> > Most of it's pretty unsurprising, but the one thing that caught me off
> > guard was that they actually ship unfinished features, but disable
> > them. The implication seemed to be that they do all development on a
> > single branch and just conditionally disable a feature until it's
> > ready.
> >
> > I've never worked in a group that ran this way, and I thought more or
> > less everyone had now converged on the model of feature branches that
> > are merged back into your master/trunk when they're ready. Do any of
> > you work in a team where all development happens on a single branch
> > and, if so, does it actually work productively?
> >
> > Cheers,
> > Matt
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to
> code-pro-bon...@googlegroups.com <mailto:code-pro-bono%2Bunsu...@googlegroups.com>.
> >
> > Hi all,
> >
> > It's been a while since anyone's posted in this group, but I watched a
> > video recently that sparked some questions I wanted to ask others
> > about. Someone at work sent around this video about engineering
> > practices at Spotify: https://www.youtube.com/watch?v=Mpsn3WaI_4k.
> > Most of it's pretty unsurprising, but the one thing that caught me off
> > guard was that they actually ship unfinished features, but disable
> > them. The implication seemed to be that they do all development on a
> > single branch and just conditionally disable a feature until it's
> > ready.
> >
> > I've never worked in a group that ran this way, and I thought more or
> > less everyone had now converged on the model of feature branches that
> > are merged back into your master/trunk when they're ready. Do any of
> > you work in a team where all development happens on a single branch
> > and, if so, does it actually work productively?
> >
> > Cheers,
> > Matt
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> code-pro-bon...@googlegroups.com <mailto:code-pro-bono%2Bunsu...@googlegroups.com>.
>
> --
> You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> code-pro-bon...@googlegroups.com <mailto:code-pro-bon...@googlegroups.com>.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
Billy Huang
Feb 13, 2015, 7:24:28 PM2/13/15
to code-p...@googlegroups.com
I like the sportify idea of toggle and hidden unfinished features.
My teams worked a little like spotify, i have 4 teams about 26 developers, the development team are in sydney, melbourne, and china, and a india team doing QA.
All team works on the same epic, A team owns at least a story, team member branching per task and merge it back to develop.
If one team need to work on other teams task, they do a pull request. (this rarely happens, but sometimes need to help out other teams, and we have one core framework development, which is controlled by one team, so any one else can only edit it through pull request )
end of each sprint, hand off to the indians to make sure nothing breaks, and than merge it to master and release it,
<mailto:matthew.fernandez@gmail.com>> wrote:
>
> Hi all,
>
> It's been a while since anyone's posted in this group, but I watched a
> video recently that sparked some questions I wanted to ask others
> about. Someone at work sent around this video about engineering
> practices at Spotify: https://www.youtube.com/watch?v=Mpsn3WaI_4k.
> Most of it's pretty unsurprising, but the one thing that caught me off
> guard was that they actually ship unfinished features, but disable
> them. The implication seemed to be that they do all development on a
> single branch and just conditionally disable a feature until it's
> ready.
>
> I've never worked in a group that ran this way, and I thought more or
> less everyone had now converged on the model of feature branches that
> are merged back into your master/trunk when they're ready. Do any of
> you work in a team where all development happens on a single branch
> and, if so, does it actually work productively?
>
> Cheers,
> Matt
>
> --
> You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Code Pro Bono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to code-pro-bono+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages